Smashing Podcast Episode 19 Dengan Andy Bell: Apa Itu CUBE CSS?

Hari ini, kita berbicara tentang CUBE CSS. Apa itu, dan apa bedanya dengan pendekatan seperti BEM, SMACSS, dan OOCSS? Saya berbicara dengan penciptanya, Andy Bell, untuk mencari tahu.

Tampilkan Catatan

• CUBE CSS
• piccalilli
• Pelajari Sebelas Dari Awal - hemat 40%!
• Andy Bell dan Piccalilli di Twitter

Catatan : Pendengar Smashing Podcast dapat menghemat 40% untuk kursus Learn Eleventy From Scratch Andy menggunakan kode SMASHINGPOD .

Update mingguan

• “Apa Vitruvius Dapat Mengajarkan Kami Tentang Desain Web”
  oleh Frederick O'Brien
• “Pengantar SWR: React Hooks Untuk Pengambilan Data Jarak Jauh”
  oleh Ibrahima Ndaw
• “Bagaimana Desainer Web Dapat Membantu Restoran Menjadi Pengalaman Digital”
  oleh Suzanne Scacca
• “Panduan Praktis Untuk Menguji Aplikasi React Dengan Jest”
  oleh Adeney David Abiodun
• “Sorotan Django: Perselisihan Aset Statis Dan File Media (Bagian 4)”
  oleh Philip Kiely

Salinan

Drew McLellan: Dia adalah seorang pendidik dan desainer web lepas yang berbasis di Inggris dan telah bekerja di industri web desainer selama lebih dari satu dekade. Saat itu dia bekerja dengan beberapa organisasi terbesar di dunia, seperti Harley-Davidson, BSkyB, Unilever, Oracle, dan NHS. Bersama Heydon Pickering, dia adalah rekan penulis Every Layout, serta menjalankan Klub Tantangan Front-End yang berfokus pada pengajaran praktik terbaik pengembangan front-end melalui tantangan singkat dan menyenangkan.

Drew: Usaha terbarunya adalah Piccalilli, buletin situs web dengan tutorial dan kursus untuk membantu Anda naik level sebagai pengembang dan perancang front-end. Jadi kami tahu dia adalah pengembang dan pendidik berpengalaman, tapi tahukah Anda bahwa dia adalah orang pertama yang diizinkan berkompetisi di Crufts dengan seekor panda?

Drew: Teman-teman Smashing saya, selamat datang, Andy Bell. Hai, Andi, apa kabar?

Andy Bell: Saya hebat, terima kasih. Apa kabar?

Drew: Saya sangat baik, terima kasih banyak. Sekarang saya ingin berbicara dengan Anda hari ini tentang sesuatu yang Anda posting di situs Anda, Piccalilli, tentang metodologi CSS yang telah Anda kembangkan sendiri selama beberapa tahun terakhir. Pertama-tama, saya kira kita mungkin harus mengeksplorasi apa yang kita maksud dengan metodologi CSS karena itu bisa berarti hal yang berbeda untuk orang yang berbeda. Jadi ketika Anda memikirkan metodologi CSS, apa itu bagi Anda?

Andy: Itu pertanyaan yang bagus dan sulit untuk memulai, Drew. Hargai itu, terima kasih!

Drew: Selamat datang!

Andy: Ini yang rumit. Jadi, untuk konteksnya, saya sudah lama menggunakan BEM, dan itu adalah Block Element Modifier. Itu sudah ada sejak lama. Cara saya melihat metodologi CSS adalah, ini bukan kerangka kerja, ini adalah struktur organisasi. Begitulah cara saya suka melihatnya. Ini seperti proses hampir. Sepertinya Anda memiliki masalah yang perlu Anda selesaikan dengan CSS dan Anda menggunakan metodologi untuk menyelesaikannya untuk Anda dan menjaga segala sesuatunya dapat diprediksi dan diatur. BEM hanya melegenda untuk itu karena sangat sukses.

Andy: Kemudian Anda hampir bisa mengkualifikasikan hal-hal seperti komponen gaya dan hal semacam itu. Anda hampir dapat mengatakan bahwa mereka berorientasi pada metodologi meskipun kerangka kerja mereka sedikit lebih terjalin, tetapi tetap saja, ini adalah metodologi untuk memecah hal-hal menjadi molekul kecil. Jadi pada dasarnya itulah yang saya coba lakukan dengan CUBE CSS juga. Sebuah struktur berpikir, saya pikir saya menggambarkannya sebagai.

Drew: Jadi ini adalah aplikasi proses untuk bagaimana Anda merancang dan menulis CSS, dan itu bukan sesuatu yang didasarkan pada alat atau jenis teknologi lainnya, itu hanya semacam alur kerja. Jadi ada banyak pendekatan berbeda di luar sana. Anda menyebutkan BEM. Ada SMACSS, OOCSS, Atomic CSS. Dan kemudian Anda mendapatkan pendekatan lovechild yang tidak biasa seperti ABEM. Pernahkah Anda melihat yang itu?

Andi: Ya.

Drew: Mengapa menerbitkan milik Anda sendiri?

Andi: Ya, ya. Mengapa membuat sendiri? Itu pertanyaan yang sangat bagus. Saya pikir mereka yang mengenal saya dengan baik tahu saya suka berlayar melawan arus. Ini terutama karena saya cenderung melakukan banyak proyek yang bervariasi juga, dalam tim yang bervariasi. Jadi sangat sulit, menurut saya, untuk bekerja dengan BEM dengan pengembang tradisional karena mereka terbiasa menggunakan CSS untuk apa itu CSS: kaskade, dan lain-lain, dan itulah mengapa saya mencurinya dari bahasa .

Andy: Di sisi lain adalah metodologi yang kurang terstruktur, lebih sulit untuk bekerja dengan programmer, tipe orang JS karena mereka menyukai struktur dan organisasi dan komponen kecil, yang dapat dimengerti bekerja dengan bahasa tempat mereka bekerja.

Andy: Jadi saya menemukan diri saya di posisi ini di mana saya bekerja dengan berbagai jenis orang, berbagai jenis proyek di mana satu metodologi tidak cukup berhasil. Selama bertahun-tahun, saya hanya bermain-main dengan gagasan tentang bagaimana keadaan berjalan, dan kemudian ada hal-hal yang saya dan Heydon lakukan, Every Layout, yang menerapkan sebagian besar darinya, yaitu C, bagian komposisi , lalu saya baru saja mengembangkannya dengan sangat cepat selama enam bulan terakhir.

Andy: Satu-satunya alasan saya menulis artikel tentang itu adalah karena saya baru saja melakukan kursus ini dan saya pikir sebaiknya saya menulis beberapa materi tambahan agar orang-orang memahaminya, dan itu benar-benar meledak. Jadi mungkin metodologi kita belum selesai, Drew.

Drew: Jadi, materi kursus yang Anda susun sebenarnya menggunakan CUBE CSS sebagai metodologinya, bukan?

Andi: Ya. Jadi 50% kursus yang bagus sebenarnya adalah front-end, meskipun kursus itu tidak terbatas. Ini sangat, sangat terjalin dalam cara kita membangun front-end sehingga saya tidak bisa hanya mengatakan, "Oh, omong-omong, beginilah cara saya menulis CSS yang bagus," dan kemudian meninggalkannya. Saya tahu orang suka masuk ke detail, jadi saya seperti, apa yang akan saya lakukan adalah, saya akan menulis posting ini yang sangat panjang dan sangat rinci dan kemudian jika seseorang ingin meningkatkan keterampilan dan benar-benar memahami apa yang kami lakukan , maka mereka dapat melakukannya, dan sisanya dari sana. Dan di sinilah kita hari ini, Drew, duduk dan mengobrol tentang hal itu.

Drew: Jadi kalau ada yang sudah mengerti BEM dan mungkin sudah menggunakan BEM, misalnya, karena itu mungkin salah satu metodologi yang paling banyak diadopsi, bukan? Jadi, jika mereka sudah memahami BEM dan akan datang ke CUBE, apakah itu sesuatu yang mudah mereka adopsi? Apakah ada banyak kesamaan atau sama sekali berbeda?

Andi: Ya. Menurut saya beralih dari BEM ke CUBE mungkin merupakan transisi yang mulus, terutama cara saya masih suka menulis CSS untuk CUBE. Jadi sebagian besar hal terjadi di tingkat yang lebih tinggi. Jadi itu terjadi di tingkat kaskade dan CSS global terjadi, menggunakan utilitas untuk melakukan banyak hal. Tetapi ketika Anda masuk ke mur dan bautnya, itu adalah komponen, balok, dan elemen yang sangat mirip dengan BEM. Satu-satunya hal yang agak berbeda dari BEM adalah, alih-alih memiliki pengubah, kami menggunakan hal ini yang disebut pengecualian yang, alih-alih menggunakan kelas CSS, ternyata menjadi atribut data, yang menurut saya memberikan sedikit pemisahan yang bagus dan nyata pengecualian, yang seharusnya menjadi pengubah.

Andy: Sebagian alasan mengapa saya agak menjauh dari BEM adalah karena saya menemukan cara saya bekerja dengannya, terutama dalam sistem desain, adalah pengubah didominasi dan itu menjadi masalah karena seperti, apa peran blok saya saat ini? Karena jika saya memodifikasinya ke titik di mana itu tidak dapat dikenali secara teratur, apakah metodologi ini masih berfungsi sebagaimana mestinya?

Andy: Lalu ada seluruh token desain, hal-hal yang dilakukan Jina dengan Lightning Design System yang mulai kita adopsi sekarang. Hal-hal kelas utilitas benar-benar mulai masuk akal dengan pendekatan itu. Jadi saya hanya mengosongkan semua hal yang saya suka tentang pekerjaan orang lain dan memasukkannya ke dalam pekerjaan saya sendiri.

Drew: Anda berbicara tentang BEM, jenis pendekatan pengubah yang lepas kendali. Apakah itu salah satu masalah utama dengan BEM yang coba diatasi oleh CUBE?

Andi: Ya, tentu saja. Saya suka pendekatan pengubah dengan BEM, itu masuk akal. Apa yang saya suka tentang BEM adalah sesuatu yang masih saya lakukan, adalah garis bawah ganda untuk sebuah elemen, dan kemudian ada tanda hubung ganda untuk pengubah. Saya suka cara mengatur sesuatu. Itu hanya kasus oke, yah, banyak pengubah yang benar-benar dapat saya pertanggungjawabkan dengan kelas utilitas dan kemudian bit lainnya ...

Andy: Jadi contoh yang saya gunakan dalam artikel ini adalah, bayangkan Anda punya kartu dan kemudian kartu dibalik, sehingga konten muncul sebelum gambar. Jadi masuk akal, untuk melihat tampilan: tekuk dan kemudian Anda membalikkannya, membalik urutannya. Itu masuk akal, untuk memiliki aturan pengecualian untuk itu karena itu pengecualian dari status default kartu, dan itulah yang saya suka melihatnya. Ini seperti keadaan yang terpengaruh pada komponen itu, yang merupakan pengecualian, dan itu masuk akal.

Andy: Dengan banyak hal yang telah saya lakukan baru-baru ini, tumpukan front-end modern dengan JavaScript reaktif, ada banyak perubahan status dan masuk akal untuk menanganinya dengan tepat antara CSS dan JavaScript karena mereka menjadi lebih dan lebih terjalin satu sama lain, apakah Anda suka atau tidak. Itu adalah bahasa yang umum bagi mereka. Seperti yang bisa Anda lihat dari wajah saya, sangat tidak, tapi begitulah. Anda mungkin berpikir, "Sebenarnya, saya telah bekerja dengan cukup banyak reaksi baru-baru ini, jadi saya sebaliknya." Jadi saya juga bisa melihatnya.

Drew: Kalau begitu mari kita masuk ke CUBE. Jadi CUBE adalah singkatan dari Composition Utility Block Exception. Apakah itu benar?

Andi: Ya. Itu dia.

Drew: Apa artinya itu?

Andy: Oh, sobat, Anda seharusnya sudah mendengarnya sebelumnya! Saya melakukan pembicaraan tahun lalu. Saya berbicara, dan itu disebut Menjaga Sederhana dengan CSS yang menskala, dan di sana saya semacam memperkenalkan versi sebelumnya yang disebut CBEUT, yang merupakan Token Utilitas Elemen Blok Cascade. Itu sampah. Aku benci nama itu. Saya melakukannya beberapa kali, pembicaraan ini tahun lalu, dan saya benar-benar tidak suka namanya. Kemudian ketika saya datang untuk melakukan hal ini tahun ini, saya berpikir, "Saya benar-benar perlu memikirkan apa itu sebenarnya dan apa namanya." Saya pikir CUBE sedikit kurang sampah. Saya pikir itu cara terbaik yang bisa saya gambarkan.

Andy: Tapi kalau begitu, nama selalu sampah untuk hal-hal ini, bukan? Maksud saya, seperti BEM, itu nama sampah! Tapi kita semua melakukannya. Lihat Jamstack: itu nama yang buruk juga, bukan?

Drew: Bibirku terkunci!

Andy: Bos Anda bertanya, "Apa?" Itu benar. Memang seperti itu, bukan, di industri kita.

Drew: Tampaknya banyak metodologi CSS mencoba dan mengatasi beberapa fitur CSS, hal-hal seperti kaskade. Pemahaman saya dari apa yang saya baca adalah, CUBE mencoba memanfaatkan fitur dan properti CSS semacam itu.

Andi: Ya. Analogi yang bagus untuk itu 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. Mari kita jujur, bahwa bagaimana seharusnya ditulis, adalah namanya memberikannya: 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 ... dan 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 pengatur jarak dan hal-hal seperti itu, dan saya memahami masalah itu, saya pernah berada dalam situasi itu.

Andy: 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 pergi menjadi halaman, mereka akan dilihat. Anda tidak dapat menghindarinya, 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. ” 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, itu tidak masalah. Kemudian komponen harus, pada saat itu, berperilaku seperti yang Anda inginkan, dengan atau tanpa kueri penampung.

Drew: Ini adalah bagian komposisi CUBE di mana Anda melihat hal-hal di tingkat makro, melihat bagaimana komponen dapat disusun menjadi tampilan untuk membuat jenis halaman yang perlu Anda buat untuk situs atau aplikasi atau apa yang kamu miliki.

Andy: Jadi itu menciptakan aturan, pada dasarnya. Ini seperti bimbingan. Itu mencoba untuk mendapatkan pedoman untuk sesuatu. Ini tidak seperti aturan yang ketat, seperti, Anda harus melakukan ini, Anda harus melakukan itu. Pada dasarnya itulah yang Anda lakukan dengan browser, dengan metodologi ini, maksud Anda... Anda tidak memaksanya untuk melakukan apa pun. Anda berkata, “Dengar, idealnya, jika Anda bisa meletakkannya seperti ini, itu akan bagus, tapi saya mengerti bahwa mungkin tidak demikian, jadi inilah beberapa batasan dan beberapa level atas dan bawah yang bisa kita kerjakan. Lakukan apa yang Anda bisa, dan bersorak. ” Kemudian Anda hanya membuang beberapa komponen dan membiarkannya melakukan apa yang dilakukannya. Anda menambahkan kontrol yang cukup di sana agar tidak terlihat sampah.

Andy: Jadi contoh yang bagus akan melihat ... kami melakukan tata letak di Setiap Tata Letak yang disebut pengalih, yang pada dasarnya akan memasukkan item ke dalam baris sampai titik tertentu di mana perhitungan yang menentukan seberapa lebar seharusnya hanya akan menumpuknya di atas satu sama lain . Tetapi karena kami menambahkan margin ke in-line dan blok, itu berfungsi, terlepas dari statusnya, itu masih terlihat baik-baik saja. Itu idenya, adalah bahwa kami tidak memberi tahu browser untuk mengatakan, "Anda harus melapisi kisi tiga kolom ini." Kami berkata, “Jika Anda dapat melapisi kotak tiga kolom, lakukanlah. Jika tidak, cukup tumpuk dan beri ruang sebagai gantinya. ” Jadi metodologi semacam itu, membiarkan browser melakukan tugasnya dengan sungguh-sungguh.

Drew: Banyak pendekatan berbeda yang muncul untuk CSS selama beberapa tahun terakhir sangat terfokus pada tingkat komponen dalam menangani segala sesuatu seperti komponen. CUBE tidak terlalu mengecilkan aspek komponen itu, itu hanya memberikan konsep ekstra ini di atas mengambil komponen-komponen itu dan menyusunnya menjadi tata letak yang lebih besar, daripada hanya mengatakan tata letak hanyalah komponen lain.

Andy: Ya, itu poin yang bagus, ya. Saya pikir hal yang harus dikatakan tentang komponen adalah komponen itu penting, terutama dalam hal-hal front-end modern. Kami melakukan banyak hal komponen, hal sistem. Tapi cara saya melihat sebuah komponen adalah, ini adalah kumpulan aturan yang memperluas apa yang sudah dilakukan.

Andy: Maksud saya dalam artikel ini adalah, pada saat Anda turun ke level blok, sebagian besar gaya Anda sebenarnya telah selesai, dan apa yang sebenarnya dilakukan komponen Anda adalah menandai Is dan melintasi T dan dikatakan, “Benar, dalam konteks ini…” Jadi untuk kartu, misalnya, buat gambar memiliki tinggi minimum X, dan tambahkan sedikit padding di sini. Lakukan ini, itu dan yang lainnya. Letakkan tombol di sini. Ini hanya semacam aturan tambahan di atas apa yang sudah diwarisi dari sisa CSS. Saya pikir itu mungkin cara terbaik untuk menggambarkannya.

Andy: Padahal di BEM komponen itu sumber kebenarannya. Sampai Anda meletakkan kelas itu pada elemen, tidak ada yang diterapkan pada saat itu, dan metode itu berfungsi. Saya baru saja menemukan saya menulis lebih banyak CSS dengan melakukan itu, dan lebih banyak CSS berulang, yang tidak saya sukai.

Drew: Apakah Anda mempertimbangkan tipografi dan warna dan ritme vertikal, spasi, dan semua itu, apakah semua itu bagian dari gagasan komposisi dalam model ini?

Andi: Ya. Dalam CSS global, ya, tentu saja. Ritme vertikal khususnya, dan alirannya. Kami membuat artikel tentang itu di 24 cara, bukan, beberapa tahun yang lalu, komponen aliran dan ritme. Itu adalah semacam abstrak dari pendekatan ini juga, di mana Anda menetapkan komponen dasar yang pada dasarnya menggunakan pemilih burung hantu yang dilobotomi. Saya tidak tahu bagaimana saya akan menggambarkannya di radio, tetapi kami akan melakukannya. Kami hanya akan menempatkan, saya pikir, dalam catatan acara tentang artikel Heydon atau sesuatu. Tapi pada dasarnya itu, ia memilih elemen anak… maaf, elemen saudara.

Andy: Jadi dikatakan, "Benar, setiap elemen yang mengikuti elemen X memiliki margin atas biaya CSS dan nilai properti," dan kemudian keindahannya adalah Anda dapat mengatur nilai properti kustom CSS pada konteks komposisi juga. Jadi Anda dapat mengatakan, "Benar, dalam komponen ini, jika ada beberapa aliran di perjalanan, kami akan menyetel ruang aliran menjadi dua rem karena kami ingin itu bagus dan gemuk, ruang yang lebar." Kemudian di bagian lain Anda mungkin berkata, “Sebenarnya, saya ingin ruang aliran menjadi setengah rem karena saya ingin itu kencang.” Ini semua terjadi, semua kontrol datang dari tingkat yang lebih tinggi dan kemudian apa yang Anda lakukan adalah, Anda menambahkan penggantian kontekstual daripada menciptakannya kembali setiap kali, menciptakan kembali hal yang sama berulang-ulang.

Drew: Jadi itu C, Komposisi. Selanjutnya kita punya U, yaitu Utilitas. Jadi apa yang kita maksud dengan utilitas?

Andy: Jadi, ini adalah kelas yang melakukan satu pekerjaan, dan melakukannya dengan sangat baik. Itu bisa menjadi implementasi dari token desain yang… merupakan abstrak properti. Biasanya warna atau gaya tipografi, ukuran, dan aturan seperti itu. Idenya adalah Anda membuat kelas utilitas yang menerapkannya. Jadi, Anda memiliki utilitas yang akan menerapkan primer latar belakang, yang seperti warna primer, dan kemudian warna primer, yang merupakan warna teks. Kemudian Anda dapat membuat beberapa token spasi untuk bantalan marjinal, dan hal-hal semacam itu. Mereka hanya melakukan satu pekerjaan. Mereka hanya menambahkan satu aturan spasi, satu aturan warna, dan hanya itu.

Andy: Tapi kemudian Anda punya utilitas lain juga. Jadi contoh yang baik adalah utilitas pembungkus. Apa yang akan dilakukan adalah, itu akan menempatkan lebar maksimum pada suatu elemen dan kemudian akan menempatkan margin otomatis kiri dan kanan untuk meletakkannya di tengah-tengah hal itu. Jadi itu hanya punya satu pekerjaan, dan itu hanya melakukannya dengan efisien dan baik.

Andy: Jadi Anda mendapatkan gaya global Anda, Anda telah melakukan banyak pengaturan tipografi dan banyak ruang lantai Anda. Komposisi Anda kemudian memberikan konteks dan tata letak. Kemudian utilitas menerapkan token langsung ke elemen untuk memberi mereka gaya yang Anda butuhkan. Jadi seperti judul, misalnya, Anda berkata, "Saya ingin ini menjadi ukuran ini dan saya ingin memiliki petunjuk ini, dan saya ingin memiliki ukuran ini." Kemudian pada titik itu… inilah yang saya katakan tentang balok-balok itu… kemudian Anda melangkah lebih jauh ke bawah tumpukan, dan Anda telah melakukan sebagian besar pekerjaan pada titik itu.

Andy: Jadi mereka memberi Anda cara kerja yang sangat efisien ini, dan karena HTML juga mengalir ke pipa, sangat bagus untuk mengabstraksikan beban kerja ke HTML daripada CSS juga, saya temukan. Saya dulu benar-benar masuk ke kelas utilitas, seperti dalam gaya lama yang kasar seperti, "Oh, pemisahan masalah," tapi saya benar-benar berpikir itu cara kerja yang benar-benar layak. Saya menyebutkan di artikel bahwa saya sebenarnya menyukai Tailwind CSS. Saya pikir itu berhasil, dan saya sangat suka menggunakannya untuk pengetikan produk karena saya benar-benar dapat mengeluarkan sesuatu dengan sangat cepat. Tapi menurut saya itu terlalu berlebihan, bukan Tailwind, sedangkan saya suka menghujaninya saat itu lebih dari sekadar menerapkan satu aturan di kelas. Jadi itu saja, saya pikir. Apakah kamu?

Drew: Jadi, ya, Anda berbicara banyak di artikel tentang token desain, yang merupakan sesuatu yang telah kita bicarakan di Podcast Smashing dengan Jina Anne di episode tiga, saya pikir itu. Jadi sepertinya token desain adalah aspek yang sangat mendasar.

Andi: Ya. Ya Tuhan, ya. Saya ingat dengan jelas ketika Jina melakukan hal-hal Sistem Desain Petir karena saya sedang membangun sistem desain pada saat itu, atau sesuatu yang menyerupai sistem desain, dan kami berjuang untuk mendapatkan persetujuan eksekutif untuk itu. Ketika Sistem Desain Petir keluar, saya benar-benar hanya mengirimi mereka tautan demi tautan dan saya berkata, “Ini yang sedang kami lakukan. Kami sedang membangun sistem desain. Inilah yang digunakan Salesforce saat ini.” Saya ingat pekerjaannya pada saat itu benar-benar membantu saya mengeluarkan barang-barang melalui pintu.

Andy: Kemudian hal-hal token desain selalu melekat pada saya sebagai cara yang sangat baik untuk menerapkan aturan-aturan ini. Karena saya seorang desainer, jadi saya bisa melihat bahwa organisasi dan kemampuan untuk mengatur dan menciptakan satu sumber kebenaran menjadi sangat berguna karena itu adalah sesuatu yang tidak benar-benar kita miliki dalam desain digital, terutama di Adobe era bekerja dengan Photoshop dan sejenisnya, kami tidak memiliki kemewahan itu. Kami mencetaknya dengan Buku Pantone tetapi kami tidak memilikinya dalam bentuk digital dengan kode hex acak di seluruh toko.

Andy: Jadi itu bagus. Saya suka tingkat kontrol itu. Sebenarnya, saya pikir itu membantu kreativitas karena Anda tidak lagi memikirkan hal-hal yang tidak penting, Anda hanya memikirkan apa yang Anda lakukan dengannya.

Drew: Apakah implementasi token desain itu penting terutama dengan pendekatannya? Apakah selalu properti khusus CSS?

Andy: Saya pikir itu poin yang sangat penting dengan CUBE. Beberapa tanggapan yang saya miliki, orang-orang telah berjuang dengan ini sedikit. Tidak ada penyebutan teknologi di dalamnya sama sekali. Satu-satunya teknologi yang konsisten adalah CSS. Anda dapat melakukannya sesuka Anda. Anda dapat melakukan semua ini dengan CSS dan JS apa pun yang dilakukan orang sekarang, atau Anda dapat melakukannya hanya dengan Vanilla CSS. Anda bisa melakukannya dengan Sass. Saya melakukannya dengan Sass. Kurang, jika itu yang masih Anda lakukan. Semua teknologi yang tersedia ini, posting CSS, semua hal ini. Anda dapat melakukan apa pun yang Anda inginkan, itu tidak masalah.

Andy: Idenya adalah jika Anda mengikuti konstruksi semacam itu, Anda akan baik-baik saja. Itulah ide di baliknya. Ini sangat longgar dan tidak ketat seperti beberapa metodologi. Saya telah melihatnya dengan BEM khususnya, orang-orang benar-benar tertanam dalam prinsip-prinsip BEM ke titik di mana Anda bahkan tidak memecahkan masalah lagi. Saya pikir Anda harus fleksibel. Saya mengatakannya dalam pembicaraan ini tahun lalu. Saya seperti, "Jika Anda berpegang teguh pada senjata Anda terlalu erat, Anda sebenarnya dapat menyebabkan masalah bagi diri Anda sendiri dalam jangka panjang karena Anda mencoba dan mengikuti jalan tertentu, dan Anda tahu itu tidak berhasil lagi." Anda harus selalu fleksibel dan bekerja dengan sistem daripada bekerja sesuai dengan surat itu.

Drew: Jadi B, B adalah Blok. Anda telah membicarakan ide ini, bahwa pada saat Anda turun ke level blok, sebagian besar dari semuanya harus berada di tempatnya, dan kemudian penataan level blok hanya benar-benar berkaitan dengan detail sebenarnya dari komponen tertentu. Secara umum, apakah konsep balok mirip dengan yang biasa dikenal orang?

Andy: Oh, tentu saja, ya. Jadi bayangkan komponen BEM Anda dan keluarkan semua hal visual darinya, dan itulah yang tersisa, pada dasarnya, bloknya. Inilah yang saya perjuangkan untuk mengartikulasikan ketika saya pertama kali mulai memikirkan metodologi ini. Sebuah blok sebenarnya adalah C, itu adalah komposisi, tetapi itu membuatnya sangat sulit karena Anda berada di wilayah rekursif di sana dan saya pikir otak orang akan meledak. Tapi sebenarnya itulah blok, sebenarnya ini adalah lapisan komposisi lain tetapi lebih dari semacam konteks yang ketat, jadi seperti kartu Anda, tombol Anda, korsel Anda, jika itu yang Anda suka lakukan, dan semua hal semacam itu.

Andy: Ini seperti hal tertentu, sebuah komponen, dan kemudian di dalamnya Anda menetapkan aturan khusus untuk diikuti, benar-benar mengabaikan sisanya jadi Anda tidak… Anda mungkin menerapkan token di blok, dan saya melakukannya masih, tapi sebenarnya itu lebih berorientasi pada tata letak, adalah blok, sejauh saya bekerja dengan mereka, atau setidaknya mengambil token dan menerapkannya dengan cara tertentu, seperti status tombol melayang, hal-hal seperti itu. Jadi benar-benar blok Anda harus kecil pada saat Anda turun ke mereka, mereka seharusnya tidak melakukan banyak hal sama sekali.

Drew: Jadi bisa sekecil hyperlink.

Andi: Ya.

Drew: Tapi itu bisa juga merupakan kumpulan gabungan dari balok-balok lain?

Andi: Ya. Seperti semacam modul. Anda pasti bisa melakukannya. Karena, sekali lagi, itu kembali ke jenis aspek komposisinya, adalah bahwa apa pun yang ada di dalamnya seharusnya tidak menjadi masalah. Contoh bagusnya adalah seperti kartu. Jadi isi sebuah kartu, katakanlah, seperti heading, ringkasan, dan tombol. Anda seharusnya tidak secara khusus menargetkan ketiga elemen tersebut. Anda harus mengatakan, "Lihat, apa pun yang terjadi untuk menemukan dirinya dalam konten, memiliki beberapa aturan aliran di sana dan memiliki semacam aturan tata letak komposisional," dan kemudian tidak peduli apa yang Anda masukkan ke sana. Anda mungkin memutuskan bahwa Anda ingin meletakkan gambar di konten itu dan itu seharusnya berfungsi, seharusnya terlihat baik-baik saja.

Andy: Itulah inti dari bekerja dengan CSS. Ini adalah cara yang sangat memaafkan untuk bekerja dengan CSS. Anda membuat hidup Anda jauh lebih mudah dengan menjadi tidak terlalu kaku karena ketika hal-hal secara tidak sengaja menemukan dirinya dalam sesuatu, yang akan terjadi, itu tidak terlihat mengerikan seperti yang bisa terjadi jika Anda lebih spesifik tentang berbagai hal, itulah yang saya ditemukan.

Drew: Saya benar-benar membutuhkan banyak pengampunan di sekitar CSS saya!

Andy: Saya tahu Anda tahu!

Drew: Semangat! Jadi itu B. Yang terakhir adalah E: E adalah Exception. Sekarang kita tidak berbicara tentang pesan kesalahan, bukan?

Andi: Tidak, tidak. Ini semacam-

Drew: Kami tidak berbicara tentang pengecualian JavaScript.

Andi: Ya, ya. Seharusnya tidak ada itu pada saat ini. Saya seharusnya tidak berharap, jika tidak, Anda benar-benar berada di hutan pada saat itu: Saya tidak berpikir saya akan dapat membantu Anda! Ide keseluruhan dari ini adalah... jadi Anda telah membuat konteks dengan blok Anda, dan pengecualiannya persis seperti itu, itu seperti pengecualian terhadap aturan: jadi kartu yang dibalik, atau mungkin tombol hantu. Jadi, Anda tahu tombol-tombol yang baru saja mendapat bingkai dan latar belakang transparan? Itu akan menjadi pengecualian karena tombol mungkin memiliki warna latar belakang yang solid dan kemudian warna label. Jadi itu menciptakan semacam keadaan variasi yang berbeda.

Andy: Alasan mengapa saya melakukan ini dengan atribut data alih-alih kelas, dan alasan mengapa itu adalah karena a) Saya pikir itu bagus untuk memiliki perbedaan. Jadi ketika Anda memindai melalui banyak HTML, Anda dapat melihat data, tanda hubung sesuatu, Anda seperti, "Benar, oke, sesuatu pasti telah berubah pada elemen ini." Hal lainnya adalah sangat bagus untuk memberikan akses JavaScript ke status itu, dan sebaliknya juga. Jadi saya sangat suka menerapkan status dengan atribut data di JavaScript. Saya pikir pada dasarnya itulah tujuan mereka, semacam lapisan komunikasi. Keharmonisan di antara mereka tampaknya bekerja dengan sangat baik.

Andy: Jadi contoh yang baik adalah, katakanlah Anda mendapat pesan status dan kemudian JavaScript akan menambahkan status data apakah berhasil, error atau informasi, atau apalah. Anda kemudian dapat menghubungkannya dengan gaya pengecualian Anda di CSS. Jadi Anda tahu itu pengecualian dari komponen status dan itu bertentangan dengan status defaultnya. Jadi itu hanya cara yang sangat berguna untuk bekerja dengan berbagai hal. Ini dapat diprediksi di kedua ujungnya: dapat diprediksi di ujung CSS, dan juga dapat diprediksi di ujung JavaScript.

Drew: Saya rasa cukup bagus bahwa sesuatu yang tidak diberikan oleh nama kelas adalah properti dan nilai. Jadi jika Anda ingin memiliki sesuatu seperti itu yang merupakan negara bagian, dan itu bisa berupa keberhasilan atau kegagalan atau peringatan atau apa pun yang Anda miliki, Anda dapat secara khusus menangani properti negara bagian itu dan membalikkan nilainya. Sedangkan dengan daftar nama kelas yang panjang, jika Anda memanipulasinya dalam JavaScript, misalnya, Anda harus melihat masing-masing dari mereka dan menambahkan logika bisnis di sana yang mengatakan, “Saya hanya dapat mengatur salah satunya,” dan apa yang terjadi jika dua kelas tersebut diterapkan pada elemen yang sama? Anda tidak bisa mendapatkannya dengan atribut data, itu hanya memiliki satu nilai.

Andi: Ya. Itu cara yang baik untuk mengatakan itu, ya. Hal ini sangat membantu, saya telah menemukan, untuk bekerja seperti itu.

Drew: Itu cukup menarik. Saya tidak berpikir saya telah melihat metodologi lain yang mengambil pendekatan itu. Apakah itu benar-benar unik untuk CUBE, melakukan itu?

Andi: Mungkin saja. Saya tidak terlalu memperhatikan hal-hal lain, yang seharusnya saya lakukan. Orang lain mungkin melakukan itu. Saya akan memberitahu Anda sekarang, itu adalah aspek yang paling kontroversial. Beberapa orang benar-benar tidak menyukai gagasan menggunakan atribut data. Masalahnya juga, dan bagaimana saya merespons, adalah, lakukan apa yang Anda inginkan. Kami tidak menyuruh Anda untuk melakukan sesuatu dengan cara tertentu, itu hanya saran. Jika Anda ingin melakukan pengecualian untuk kelas CSS, seperti pengubah, maka kalahkan diri Anda. Polisi CUBE tidak akan datang mengetuk pintu Anda. Ini baik-baik saja.

Andy: CUBE adalah sesuatu yang berpikir, itu adalah sebuah struktur. Anda menerapkan struktur itu sesuka Anda, dengan alat apa yang Anda inginkan, atau teknologi apa pun yang Anda inginkan. Selama Anda menjaga hal-hal konsisten, itu yang penting.

Drew: Jadi tidak ada yang namanya CUBE murni?

Andy: Cara saya menulisnya adalah CUBE murni, Drew. Semua orang hanya palsu, itu hanya tiruan yang lemah.

Drew: Selain Anda, tidak ada yang bisa mengatakan, "Itu bukan buku teks CUBE."

Andi: Tidak, itu saja. Tidak ada yang bisa membantahnya, bukan? Jadi, ya, saya akan pergi dengan itu. Memberi Anda sedikit pengaruh atau sesuatu, saya pikir, sesuatu seperti itu.

Drew: Bisakah Anda mencampur dan mencocokkan pendekatan CUBE dengan metodologi lain? Bisakah Anda menggunakan bit BEM?

Andy: Ya, saya rasa begitu. Saya telah memikirkannya sedikit karena saya akan melakukan beberapa hal lagi segera karena itu menjadi sangat populer, sehingga orang akan menginginkan lebih banyak pekerjaan. Satu hal yang akan saya lihat adalah bagaimana pendekatan menggunakan metodologi CUBE dengan sesuatu yang sudah ada.

Andy: Jadi ada dua ujung timbangan yang berlawanan. Pertanyaan bagus yang diajukan orang adalah: "Bagaimana cara kerjanya dengan setiap tata letak, hal-hal lain?" Saya seperti, pada dasarnya, setiap tata letak adalah C. Begitulah setiap tata letak, itu adalah lapisan komposisi. Kemudian orang lain bertanya, “Bagaimana ini bekerja dengan sesuatu seperti Atomic Web Design, seperti yang dilakukan Brad Frost? Ini seperti, Anda bisa memecah bagian-bagian itu dan menerapkannya di setiap level. Desain Atom berjalan hingga ke detail mikro. Ini mengabstraksikannya menjadi menggunakan, benar, oke, saya bisa menerapkan ini dengan utilitas, jadi molekul, saya pikir. Saya dapat menerapkannya dengan utilitas, dan itu menerjemahkan apa yang sudah Anda ketahui ke dalam struktur kerja yang sedikit berbeda ini.

Andy: Sungguh, ini adalah penggantian nama untuk banyak hal. Saya tidak menemukan apa pun di sini, saya hanya semacam, seperti yang saya katakan, saya baru saja mencuri barang-barang yang saya sukai. Saya suka cara beberapa hal Desain Atom dipikirkan. Itu benar-benar pekerjaan yang cerdas. Dan BEM. Hal-hal yang dilakukan Harry, CSS Segitiga Terbalik, menurut saya itu sangat keren. Jadi saya baru saja mengurutkan potongan-potongan yang saya suka dari masing-masing dari mereka dan semacam dijahit mereka semua bersama-sama ke dalam hal hibrida lainnya, pendekatan. Lebih banyak lagi yang akan datang, saya pikir.

Drew: Bisakah pendekatan CUBE diterapkan ke proyek yang sudah ada yang sudah memiliki CSS atau apakah itu sesuatu yang benar-benar Anda perlukan untuk memulai proyek baru?

Andy: Itu sangat tergantung. Jadi, jika Anda memiliki pekerjaan bootstrap dan hanya memiliki ribuan baris CSS khusus, yang saya pasti pernah terlibat sebelumnya, maka saya pikir Anda mungkin mencoba memadamkan api dengan sebotol air pada saat itu. titik. But if you… say, for instance, if you've got a rough BEM setup and it's gone a bit layer-y, you could use CUBE to refactor and actually pull it back into shape again.

Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!

Drew: Especially if your BEM site's gone layer-y.

Andy: Yeah. Nothing worse than a layer-y BEM site!

Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.

Andy: Oh, God, yeah. Tell you what, Drew-

Drew: What is that about? Tentang apa itu?

Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.

Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.

Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.

Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.

Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?

Drew: Ya.

Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.

Drew: Slash, what's with the brackets?

Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.

Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-

Andy: Yeah. Oh, God, yes.

Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.

Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.

Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.

Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?

Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.

Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.

Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.

Drew: What's the response been like to CUBE since you published the article?

Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.

Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.

Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?

Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.

Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. Ini adalah apa itu. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.

Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? What's it all about?

Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.

Andy: Saya ingin melakukan sesuatu yang sedikit berbeda dan menerapkan pengetahuan yang saya miliki dan benar-benar membagikannya kepada orang-orang. Saya selalu sangat terbuka dan berbagi, dan saya ingin meresmikannya. Jadi saya membuat Piccalilli untuk menulis tutorial, tetapi terutama untuk kursus yang saya hasilkan: itulah daging dan kentang utama. Lalu ada buletin yang… orang-orang sangat menikmati buletin karena saya membagikan hal-hal keren yang saya temukan di internet setiap minggu. Itulah tulang punggungnya. Ini berjalan sangat baik. Pada dasarnya di situlah saya ingin melihat diri saya melakukan lebih banyak dan lebih banyak lagi, seiring berjalannya waktu, saya pikir.

Drew: Jadi apa yang akan terjadi selanjutnya untuk Piccalilli? Apakah Anda punya sesuatu yang Anda punya keluar?

Andy: Terima kasih untuk pintu yang terbuka di sana, Drew! Saat rekaman ini dirilis, kursus pertama akan ditayangkan langsung: Learn Eleventy From Scratch, dan di sanalah kami belajar cara membuat situs web Gatsby! Tidak, Anda belajar cara membuat situs Eleventy. Jadi Anda memulai dengan direktori yang benar-benar kosong, tidak ada apa-apa di dalamnya, itu kosong, dan kemudian pada akhirnya Anda akan menyelesaikan dengan situs agensi yang sangat bagus ini. Kami belajar segala macam di dalamnya. Anda belajar bagaimana benar-benar pergi ke kota dengan Eleventy. Kami menarik data jarak jauh dari berbagai tempat. Kami menggunakan CUBE CSS untuk membangun front-end yang sangat bagus untuknya.

Andy: Jika Anda ingin masuk ke Jamstack dan Anda ingin masuk ke generator situs statis, atau hanya bagaimana membangun situs web yang bagus, itu hanya kursus yang sangat berguna, saya harap, untuk itu. Saat ini sedang diedit dalam satu inci dari hidupnya seperti yang kita bicarakan. Ini akan menjadi keren, saya harap, dan bermanfaat. Tapi itu adalah akumulasi dari banyak hal yang telah saya lakukan selama beberapa tahun terakhir. Jadi itu harus menyenangkan.

Andy: Jadi belilah, dan saya akan membuat kode diskon, lakukan seperti smashingpod dengan diskon 40%, dan Anda bisa mendapatkannya ketika sudah keluar.

Drew: Luar biasa. Kami akan menghubungkannya. Sudahkah Anda menemukan cara mengeja Piccalilli dengan andal?

Andy: Saya bersama Chris dan Dave dengan ShopTalk Show dan saya berkata di sana, "Jika ada satu hal yang Anda ingin mempekerjakan saya untuk itu adalah menulis Piccalilli dengan tangan pertama kali bahkan tanpa memikirkannya," karena saya sudah menulis kata itu berkali-kali sehingga saya hanya tahu persis bagaimana mengejanya dengan hati. Jadi jawaban untuk pertanyaan Anda adalah ya.

Drew: Yah, aku masih berjuang, aku akan memberitahumu sebanyak itu!

Andi: Sulit. Ya Tuhan. Saya benar-benar berempati. Butuh waktu lama bagi saya untuk belajar mengejanya, tetapi itu adalah salah satu kata dalam kosakata kami. Tahun ini saya mencoba mengeja yang diperlukan tanpa membuat kesalahan ejaan!

Drew: Jadi saya telah mempelajari semua tentang CUBE CSS. Apa yang kamu pelajari akhir-akhir ini, Andy?

Andi : Tahukah kamu? Ini akan mengejutkanmu, Drew. MySQL adalah apa yang saya pelajari baru-baru ini. Jadi, pada dasarnya, Piccalilli sepenuhnya diterbitkan sendiri. Ini adalah situs Eleventy tetapi memiliki API di belakangnya, dan database MySQL di belakangnya. Hal-hal yang memberi orang konten yang telah mereka beli memerlukan beberapa pertanyaan yang cukup besar dan kuat. Jadi saya baru saja benar-benar berinvestasi di beberapa MySQL… terutama perbedaan antara gabungan, yang sebenarnya tidak saya sadari ada perbedaan antara setiap jenis gabungan. Jadi itu sangat berguna dan menghasilkan beberapa interaksi yang cukup cepat dengan database.

Andy: Saya dulu menjalankan hal yang disebut Front-End Challenges Club dan ketika saya pertama kali meluncurkannya, itu runtuh dan mati dengan sendirinya karena MySQL jelek untuk sedikitnya. Jadi saya benar-benar telah belajar bagaimana melakukan itu karena saya bukan orang backend sama sekali, saya seorang pendorong piksel. Jadi itu jelas bukan wewenang saya. Itu lebih seperti leher hutanmu, bukan? Saya merasa sangat keren, MySQL. Saya sebenarnya sangat suka menulisnya. Ini benar-benar bagus, bahasa instruksional, bukan?

Drew: Ini, itu bagus. Saya belajar SQL di sekolah.

Andi: Wah!

Drew: Kami berbicara seperti 20 tahun yang lalu sekarang.

Andy: Apakah mereka memiliki komputer pada masa itu?

Drew: Mereka melakukannya, ya. Kami harus angin-

Andy: Apakah Anda harus menulisnya dengan tangan?

Drew: Kami harus menggulung mereka! Kita telah melakukannya. Tapi, saya beri tahu Anda, untuk seorang pengembang, ini mirip dengan mempelajari tabel waktu Anda: salah satu hal yang tampak seperti sedikit tugas tetapi begitu Anda fasih, itu menjadi berguna berkali-kali.

Andi: Ya. Tentunya. Ada perbedaan yang sangat nyata juga. Anda benar-benar melihat perbedaan kecepatan. Saya sangat suka bekerja dengan Node karena itu sangat cepat tetapi Node dan MySQL hanya… bukan pilihan yang sangat umum, tapi saya pikir itu pilihan yang cukup bagus. Saya pikir itu bekerja dengan sangat, sangat baik. Jadi saya senang dengan itu. Seperti yang Anda tahu, saya tidak suka menulis PHP. Jadi itu tidak akan pernah menjadi pilihan.

Drew: Jika Anda, pendengar yang baik, ingin mendengar lebih banyak dari Andy, Anda dapat mengikutinya di Twitter di mana dia berada di hankchizljaw. Anda dapat menemukan Piccalilli di piccalil.li, di mana Anda juga akan menemukan artikel yang menjelaskan CSS CUBE, dan kami juga akan menambahkan tautan ke semua itu di catatan acara, tentu saja.

Drew: Terima kasih telah bergabung dengan kami hari ini, Andy. Apakah Anda memiliki kata-kata perpisahan?

Andy: Tetap aman, dan pakai topengmu.