Andy Bell ile Çarpıcı Podcast 19. Bölüm: CUBE CSS Nedir?

Bugün, CUBE CSS hakkında konuşuyoruz. Nedir ve BEM, SMACSS ve OOCSS gibi yaklaşımlardan farkı nedir? Öğrenmek için yaratıcısı Andy Bell ile konuştum.

Notları göster

• KÜP CSS
• Piccalilli
• Eleveny'i Sıfırdan Öğrenin - %40 tasarruf edin!
• Andy Bell ve Piccalilli Twitter'da

Not : Smashing Podcast'inin dinleyicileri, SMASHINGPOD kodunu kullanarak Andy'nin Learn SMASHINGPOD From Scratch kursunda %40 gibi büyük bir tasarruf sağlayabilir.

Haftalık güncelleme

• “Vitruvius Web Tasarımı Hakkında Bize Ne Öğretebilir”
  tarafından Frederick O'Brien
• "SWR'ye Giriş: Uzaktan Veri Alma İçin Tepki Kancaları"
  tarafından Ibrahima Ndaw
• “Web Tasarımcıları Restoranların Dijital Deneyimlere Taşınmasına Nasıl Yardımcı Olabilir”
  Suzanne Scacca tarafından
• “Jest ile React Uygulamalarını Test Etmek İçin Pratik Bir Kılavuz”
  Adeneye David Abiodun tarafından
• “Django'nun Öne Çıkanları: Statik Varlıkları ve Medya Dosyalarını Uğraşmak (Bölüm 4)”
  tarafından Philip Kiely

Transcript

Drew McLellan: İngiltere'de yerleşik bir eğitimci ve serbest web tasarımcısıdır ve on yıldan fazla bir süredir tasarımcı web endüstrilerinde çalışmaktadır. Bu süre zarfında Harley-Davidson, BSkyB, Unilever, Oracle ve NHS gibi dünyanın en büyük kuruluşlarından bazılarıyla çalıştı. Heydon Pickering'in yanı sıra, Every Layout'un ortak yazarı ve aynı zamanda kısa, eğlenceli mücadelelerle ön uç geliştirme en iyi uygulamalarını öğretmeye odaklanan Ön Uç Mücadeleleri Kulübü'nü yönetiyor.

Drew: En son girişimi, ön uç geliştirici ve tasarımcı olarak seviye atlamanıza yardımcı olacak öğreticiler ve kurslar içeren bir web sitesi bülteni olan Piccalilli. Deneyimli bir geliştirici ve eğitimci olduğunu biliyoruz, ancak Crufts'ta bir panda ile rekabet etmesine izin verilen ilk kişi olduğunu biliyor muydunuz?

Drew: Smashing arkadaşlarım, lütfen hoş geldiniz Andy Bell. Merhaba Andy, nasılsın?

Andy Bell: Harikayım, teşekkürler. Nasılsınız?

Drew: Çok iyiyim, çok teşekkür ederim. Şimdi bugün sizinle Piccalilli adlı sitenizde yayınladığınız bir şey hakkında, son yıllarda kendiniz için geliştirdiğiniz bir CSS metodolojisi hakkında konuşmak istiyorum. Her şeyden önce, muhtemelen bir CSS metodolojisi ile ne demek istediğimizi keşfetmemiz gerektiğini düşünüyorum çünkü bu farklı insanlar için farklı şeyler ifade edebilir. Öyleyse, CSS metodolojisini düşündüğünüzde, size ne?

Andy: Başlamak için güzel ve zor bir soru, Drew. Bunu takdir edin, teşekkürler!

Duru: Hoş geldiniz!

Andy: Bu zor bir şey. Dolayısıyla, bağlam için BEM'i uzun süredir kullanıyorum ve bu Blok Eleman Değiştirici. Bu uzun zamandır var. Bir CSS metodolojisine bakma şeklim, bu bir çerçeve değil, bir organizasyon yapısı. İşte böyle görmek hoşuma gidiyor. Neredeyse bir süreç gibi. Sanki CSS ile çözmeniz gereken bir probleminiz var ve bunu sizin için çözmek için metodolojiyi kullanıyorsunuz ve işleri tahmin edilebilir ve düzenli tutuyorsunuz. BEM bunun için sadece efsanevi çünkü çılgınca başarılı oldu.

Andy: O zaman stil bileşenleri ve bu tür şeyler gibi şeyleri neredeyse niteleyebilirsin. Biraz daha iç içe geçmiş olsalar bile neredeyse metodoloji odaklı olduklarını söyleyebilirsiniz, ancak yine de bu, şeyleri küçük moleküllere ayırmanın bir metodolojisidir. Yani aslında benim de CUBE CSS ile yapmaya çalıştığım şey bu. Düşünen bir yapı olarak tanımladığımı düşünüyorum.

Drew: Yani bu, CSS'yi nasıl tasarladığınız ve yazdığınızla ilgili bir süreç uygulaması ve araçlara veya başka herhangi bir teknolojiye dayalı bir şey değil, sadece bir tür iş akışı. Yani orada birçok farklı yaklaşım var. BEM'den bahsettin. SMACSS, OOCSS, Atomic CSS var. Ve sonra ABEM gibi bu tür alışılmadık aşk çocuğu yaklaşımlarınız var. Bunu gördün mü?

Andy: Evet.

Drew: Neden kendi yayınınızı yayınlayasınız?

Andy: Evet, evet. Neden kendin yap? Bu çok iyi bir soru. Sanırım beni tanıyanlar akıntıya karşı yelken açmayı çok sevdiğimi bilirler. Bunun temel nedeni, çeşitli ekiplerde çok sayıda çeşitli proje yapma eğiliminde olmam. Bu yüzden, geleneksel bir geliştiriciyle BEM ile çalışmanın çok zor olduğunu buldum, çünkü onlar CSS'yi CSS'nin neyle ilgili olduğu için kullanmaya alışkınlar: kademeli, vb. ve bu yüzden bunu bir şekilde dilden çaldım. .

Andy: Diğer yandan, daha az yapılandırılmış metodolojiler, bir programcıyla çalışmak daha zordur, JS türünden bir insan çünkü onlar yapıyı ve organizasyonu ve küçük bileşenleri severler, bu da çalıştıkları dille çalışmak anlaşılabilir bir durumdur.

Andy: Kendimi farklı tipte insanlarla, bir metodolojinin tam olarak işe yaramadığı farklı tipte projelerle çalıştığım bu pozisyonlarda buldum. Yıllar boyunca, işlerin nasıl yürüdüğüne dair bu fikirle oynadım ve sonra benim ve Heydon'ın yaptığı şeyler var, Every Layout, ki bu onun büyük bir kısmını zorladı, bu da C, kompozisyon kısmı. ve son altı ayda onu çok hızlı bir şekilde geliştirdim.

Andy: Bununla ilgili bir makale yazmamın tek nedeni, sadece bu kursu yapıyor olmamdı ve insanların anlaması için onunla birlikte bazı ek materyaller yazmamın daha iyi olacağını düşündüm ve kesinlikle havaya uçtu. Belki de henüz metodolojileri bitirmedik, Drew.

Drew: Yani bir araya getirdiğin kurs materyali aslında metodoloji olarak CUBE CSS kullanıyor, öyle mi?

Andy: Evet. Yani kursun iyi bir %50'si, sınırsız bir kurs olmasına rağmen aslında ön uçtur. Ön ucu oluşturma şeklimiz o kadar çok iç içe ki, öylece "Ah, bu arada, ben böyle güzel bir CSS yazarım" diyemedim ve sonra bırakamadım. İnsanların ayrıntılara girmeyi sevdiğini biliyorum, bu yüzden yapacağım şey, gerçekten uzun ve gerçekten ayrıntılı bu gönderiyi yazacağım ve sonra eğer biri beceri kazanmak ve ne yaptığımızı gerçekten anlamak isterse , o zaman yapabilirler ve gerisi oradan. Ve bugün buradayız, Drew, oturuyoruz ve bunun hakkında konuşuyoruz.

Drew: Yani biri zaten BEM'i anlıyorsa ve belki de örnek olarak BEM'i kullanıyorsa, çünkü bu muhtemelen benimsenen en geniş metodolojilerden biridir, değil mi? Öyleyse, BEM hakkında zaten bir anlayışa sahiplerse ve CUBE'ye geliyorlarsa, bu onların benimsemesi kolay bir şey mi? Pek çok benzerlik var mı yoksa tamamen farklı mı?

Andy: Evet. BEM'den CUBE'ye geçmenin muhtemelen yumuşak bir geçiş olduğunu söyleyebilirim, özellikle de CUBE için CSS yazmayı sevdiğim şekilde. Yani çoğu şey daha yüksek bir seviyede oluyor. Bu, kademeli düzeyde oluyor ve birçok şeyi yapmak için yardımcı programları kullanarak global CSS oluyor. Ama işin özüne geldiğinizde, bunlar çok BEM benzeri bileşenler, bloklar ve elemanlardır. BEM'den biraz farklı olan tek şey, değiştiricilere sahip olmak yerine, bunun yerine istisnalar denilen şeyi kullanıyoruz, bu, CSS sınıflarını kullanmak yerine, bence güzel bir ayrım ve gerçek bir parça verdiğini düşündüğüm veri niteliklerine dönüşüyor. istisna, bir değiştiricinin olması gereken şeydir.

Andy: BEM'den ayrılmamın bir nedeni, onunla çalışma şeklimi bulmamdı, özellikle tasarım sistemlerinde, değiştiricilerin baskın olmasıydı ve bu bir sorun haline geldi çünkü şuna benziyordu: bu noktada bloğumun rolü? Çünkü onu düzenli olarak tanınmaz hale gelecek şekilde değiştiriyorsam, bu metodoloji hala olması gerektiği gibi çalışıyor mu?

Andy: Sonra tüm tasarım belirteçleri var, Jina'nın şimdi benimsemeye başladığımız Yıldırım Tasarım Sistemi ile yaptığı şeyler. Fayda sınıfı şeyleri bu yaklaşımla gerçekten anlamlı olmaya başladı. Bu yüzden, diğer insanların çalışmaları hakkında sevdiğim her şeyi bir nevi ezdim ve onun yerine kendi işime ayırdım.

Drew: BEM'den bahsediyorsunuz, bir çeşit değiştirici yaklaşım, bir nevi kontrolden çıkıyor. CUBE'nin ele almaya çalıştığı BEM ile ilgili ana sorunlardan biri bu muydu?

Andy: Evet, kesinlikle. BEM ile değiştirici yaklaşımı seviyorum, mantıklı geliyor. BEM hakkında sevdiğim şey, hala yaptığım bir şey, bir öğe için çift alt çizgi ve sonra bir değiştirici için çift çizgi var. İşleri bu şekilde organize etmeyi seviyorum. Bu sadece bir sorundu, peki, aslında faydalı sınıflarla açıklayabildiğim birçok değiştirici ve sonra diğer bitler…

Andy: Makalede kullandığım örnek, bir kartınız olduğunu ve ardından kartın ters çevrildiğini ve böylece içeriğin resimden önce göründüğünü hayal edin. Öyleyse bu mantıklı, display: flex'i görmek ve sonra onu tersine çevirirsiniz, sırayı tersine çevirirsiniz. Bunun için bir istisna kuralı olması mantıklı çünkü bu, kartın varsayılan durumunun bir istisnası ve ben bunu böyle görmeyi seviyorum. Bu bileşen üzerindeki etkilenmiş bir durum gibi, bir istisna nedir ve bu mantıklı.

Andy: Son zamanlarda yaptığım birçok şeyle, reaktif JavaScript'li modern ön uç yığınıyla, çok fazla durum değişikliği var ve CSS ile JavaScript arasında uygun şekilde halletmek mantıklı çünkü bunlar giderek daha fazla oluyor ve beğenseniz de beğenmeseniz de birbirinize daha çok sarılır. Bu onlar için ortak bir dildir. Yüzümden gördüğün gibi, pek değil, ama işte gidiyorsun. Muhtemelen, "Aslında, son zamanlarda tepki ile oldukça fazla çalışıyorum, bu yüzden tam tersiyim" diye düşünüyorsunuz. Yani bunu da görebiliyorum.

Drew: O zaman KÜP'e girelim. Yani CUBE, Kompozisyon Yardımcı Programı Blok İstisnası anlamına gelir. Bu doğru mu?

Andy: Evet. Bu o.

Drew: Bu ne anlama geliyor?

Andy: Ah, dostum, bunu daha önce duymalıydın! Geçen yıl bir konuşma yapıyordum. Bir konuşma yaptım ve adı Ölçeklenen CSS ile Basit Tutmak olarak adlandırıldı ve orada, Cascade Block Element Utility Token olan CBEUT adlı önceki bir sürümünü tanıttım. Çöptü. Adından nefret ettim. Geçen yıl bu konuşmayı birkaç kez yaptım ve ismi gerçekten hoşuma gitmedi. Sonra bu yıl bu işi yapmaya geldiğimde, "Gerçekten ne olduğunu ve ne dendiğini gerçekten düşünmem gerek" diye düşündüm. Bence CUBE biraz daha az çöp. Sanırım onu ​​tarif etmenin en iyi yolu bu.

Andy: Ama o zaman, bu tür şeyler için isimler her zaman saçmadır, değil mi? Yani, BEM gibi, ne saçma bir isim bu! Ama hepimiz yapıyoruz. Jamstack'e bakın: bu da korkunç bir isim, değil mi?

Drew: Dudaklarım mühürlü!

Andy: Patronun "Ne?" diyor. Bu doğru. Bizim sektörümüzde de böyle değil mi?

Drew: Görünüşe göre pek çok CSS metodolojisi, CSS'nin bazı özellikleri üzerinde çalışıyor ve kaskad gibi şeyler üzerinde çalışıyor. Okuduklarımdan anladığım kadarıyla CUBE, CSS'nin bu tür özelliklerini ve özelliklerini kullanmaya çalışıyor.

Andy: Evet. Bunun için iyi bir benzetme, SCSS'dir, Sass gibi, doğal CSS dilinin bir uzantısıdır, değil mi? Hala CSS'de hemen hemen haklısın. Yani CUBE CSS böyle. Yani CSS'nin bir uzantısıdır. Öyleyse biz yine de CSS yazmalıyız, CSS'nin yapması gerektiği gibi… iyi, yazılması gerekiyor. Dürüst olmak gerekirse, nasıl yazılması gerektiği, adının onu ele vermesidir: Basamaklı Stil Sayfaları. Yani bunu tekrar kucaklıyor çünkü bulduğum şey, mikro optimizasyon seviyesine kadar indiğimdir. Son zamanlarda pek çok insanın aşağı indiğini gördüğüm bir yoldan geçtim… ve bundan da makalede bahsettim, görebildiğim yerde… son zamanlarda bunun bazı kanıtları var. İnsanların aralayıcı bileşenler ve bunun gibi şeyler yarattığını fark ettim ve bu sorunu anlıyorum, ben de bu durumdaydım.

Andy: Bunu düzeltmenin yolu, derinlere inip mikro optimizasyon yapmaya çalışmak yerine, aslında bileşenlerinizin ne kadar küçük olduğunun bir önemi olmadığı için, bazı şeyleri kompozisyon düzeyinde düşünmeye başladım. sayfalar olmak için, görünümler olacaklar. Bundan kaçınamazsınız, böyle olacak. Bu yüzden, "Doğru, bu düzeni yapmak için bu küçük yardımcılara ihtiyacım var" demeye çalışmak yerine, "Doğru, bir iletişim sayfası görünümüm veya bir ürün sayfası görünümüm var ve bu bir iskelet düzeni kompozisyonu" diyorsunuz. O zaman bunun içinde istediğim bileşenleri oraya yerleştirebilirim.” Artık Grid ve Flexbox gibi bunu çok daha ulaşılabilir kılan şeyler var ve aslında istediğiniz her şeyi iskelet düzeninin içine koyabilirsiniz, önemli değil. Ardından bileşenler, bu noktada, kapsayıcı sorguları olsun veya olmasın, nasıl davranmalarını istiyorsanız öyle davranmalıdır.

Drew: Bu, CUBE'nin, şeylere daha çok makro düzeyde baktığınız, bir site veya uygulama için oluşturmanız gereken türden sayfalar oluşturmak için bileşenlerin bir görünümde nasıl oluşturulabileceğine baktığınız kompozisyon kısmıdır. ya sende ne var

Andy: Yani esasen kurallar oluşturuyor. Bu rehberlik gibidir. Bir şey için yönergeler almaya çalışıyor. Bunu yapmalısın, bunu yapmalısın gibi katı kurallar gibi değil. Esasen tarayıcıyla yaptığınız şey bu, bu metodolojiyle, diyorsunuz ki… onu hiçbir şey yapmaya zorlamıyorsunuz. “Bakın, ideal olarak, bunu böyle ortaya koyabilseydiniz harika olurdu, ancak durumun böyle olmayabileceğini anlıyorum, bu yüzden burada çalışabileceğimiz bazı sınırlar ve bazı üst ve alt seviyeler var. Elinden geleni yap ve şerefe.” Ardından, bazı bileşenleri ona fırlatırsınız ve yaptığı şeyi yapmasına izin verirsiniz. Çöp görünmemesi için oraya yeterince kontrol eklersiniz.

Andy: O halde iyi bir örnek görebiliriz... Her Yerleşim'de anahtarlayıcı adı verilen bir düzen yapıyoruz, bu da esasen belirli bir noktaya kadar satır içi öğeler olacak, burada ne kadar geniş olması gerektiğini hesaplayan hesaplama onları üst üste yığacaktır. . Ancak satır içi ve bloğa kenar boşluğu eklediğimiz için, durumu ne olursa olsun çalışıyor, yine de iyi görünüyor. Fikir bu, tarayıcıya "Bu üç sütunlu ızgarayı katmanlara ayırmalısınız" demesini söylemiyoruz. Diyoruz ki, “Üç sütunlu bir ızgarayı katmanlaştırabiliyorsanız, yapın. Aksi takdirde, bunun yerine sadece yığın ve boşluk bırakın. ” Bu, tarayıcının işini gerçekten yapmasına izin vermenin bu tür bir metodolojisidir.

Drew: Son birkaç yılda CSS için ortaya çıkan farklı yaklaşımların çoğu, her şeyi bir bileşenmiş gibi ele almanın bileşen düzeyine çok odaklandı. CUBE, bileşen yönünü o kadar da önemsiz görmez, sadece yerleşimin sadece başka bir bileşen olduğunu söylemek yerine, bu bileşenleri alıp daha büyük yerleşimler halinde oluşturmanın üstüne bu ekstra konsepti verir.

Andy: Evet, bu iyi bir nokta, evet. Bileşenler hakkında söylenecek şey, özellikle modern ön uç şeylerde önemli olduklarıdır. Bir sürü bileşen işi yapıyoruz, sistem işi. Ama bir bileşeni görme şeklim şu ki, o zaten yapılmış olanı genişleten bir kurallar topluluğu.

Andy: Makalede değindiğim nokta, blok seviyesine indiğiniz zaman, stilinizin çoğu tamamlanmış oluyor ve aslında bileşeninizin yaptığı şey, Is'i noktalamak ve T'leri geçmek ve diyor ki, “Doğru, bu bağlamda…” Yani, örneğin bir kart için, görüntünün minimum X yüksekliğine sahip olmasını sağlayın ve buraya biraz dolgu ekleyin. Bunu, bunu ve diğerini yap. Buraya bir düğme koyun. Bu, CSS'nin geri kalanından zaten devralınanların üzerine ek kurallardır. Sanırım bunu tanımlamanın en iyi yolu bu.

Andy: Oysa BEM'de bileşen gerçeğin kaynağıdır. O sınıfı elemente koyana kadar, o noktada hiçbir şey uygulanmadı ve bu yöntem işe yarıyor. Bunu yaparak daha fazla CSS yazdığımı ve yapmaktan hoşlanmadığım daha fazla tekrarlayan CSS yazdığımı öğrendim.

Drew: Tipografiyi, renkleri ve dikey ritimleri, aralıkları ve bunların hepsini bu modeldeki kompozisyon fikrinin bir parçası mı diye düşünür müsünüz?

Andy: Evet. Küresel bir CSS'de, evet, kesinlikle. Özellikle dikey ritim ve akış. 24 şekilde bununla ilgili bir makale yapmıştık, değil mi, birkaç yıl önce akış ve ritim bileşeni. Bu, aynı zamanda, lobotomize baykuş seçiciyi esas olarak kullanan bir temel bileşen belirlediğiniz bu yaklaşımdan bir tür soyuttu. Bunu radyoda nasıl anlatacağımı bilmiyorum ama anlatacağız. Sanırım gösteriye Heydon makalesi falan hakkında notlar koyacağız. Ama aslında, alt öğeleri seçer… üzgünüm, kardeş öğeler.

Andy: Yani, "Doğru, X öğesini takip eden her öğenin üst marjı CSS maliyetlerine ve özellik değerine sahip" diyor ve bunun güzelliği, o zaman bu CSS özel özellik değerini bir kompozisyon bağlamında da ayarlayabilmenizdir. Yani, "Doğru, bu bileşende, hareket halindeyken bir akış varsa, akış alanını aslında iki rem olacak şekilde ayarlayacağız çünkü onun güzel ve etli, geniş alan olmasını istiyoruz" diyebilirsiniz. Sonra bir diğerinde, "Aslında akış alanının yarım rem olmasını istiyorum çünkü dar olmasını istiyorum" diyebilirsiniz. Bunların hepsi oluyor, tüm kontrol daha yüksek bir seviyeden geliyor ve sonra yaptığınız şey, her seferinde yeniden icat etmek yerine bağlamsal geçersiz kılmalar ekliyorsunuz, aynı şeyi tekrar tekrar icat ediyorsunuz.

Drew: Demek bu C, Kompozisyon. Sonra U, yani Yardımcı Programımız var. Peki faydadan ne anlamalıyız?

Andy: Yani bir işi yapan bir sınıf ve bunu gerçekten iyi yapıyor. Bu, özelliklerin bir özeti olan bir tasarım belirtecinin bir uygulaması olabilir. Genellikle renkler veya tipografi stilleri, boyutlandırma ve bunun gibi kurallardır. Buradaki fikir, bunları uygulayan yardımcı program sınıfları oluşturmanızdır. Böylece, birincil renk gibi arka plan birincilini ve ardından metin rengi olan birincil rengi uygulayacak bir yardımcı programınız var. Ardından, marjinal dolgu ve bunun gibi şeyler için bazı boşluk belirteçleri oluşturabilirsiniz. Sadece bir iş yapıyorlar. Sadece o tek boşluk kuralını, o tek renk kuralını ekliyorlar ve hepsi bu.

Andy: Ama sonra başka yardımcı programların da var. Bu yüzden iyi bir örnek, bir sarmalayıcı yardımcı programıdır. Bunun yapacağı şey, bir öğeye maksimum genişlik koyacak ve sonra onu şeyin ortasına oturtmak için sol ve sağ otomatik kenar boşluğunu koyacaktır. Yani sadece bir işi var ve bunu verimli ve iyi yapıyor.

Andy: Demek global tarzlarına sahipsin, birçok tipografi ayarını yaptın ve döşeme alanının çoğunu yaptın. Kompozisyonunuz daha sonra bağlam ve düzen veriyor. Ardından, yardımcı programlar, ihtiyacınız olan stili vermek için öğeleri doğrudan öğelere uygular. Yani bir başlık gibi, örneğin, "Bunun bu boyutta olmasını istiyorum ve bu önde olmasını istiyorum ve bu ölçüye sahip olmasını istiyorum" diyorsunuz. Sonra o noktada… bloklar hakkında söylediğim şey buydu… o zaman yığının aşağısına iniyorsunuz ve işin çoğunu zaten o noktada yaptınız.

Andy: Yani size gerçekten verimli bir çalışma yöntemi sunuyorlar ve HTML de borudan aşağı aktığından, iş yükünü CSS yerine HTML'ye soyutlamak gerçekten güzel, buldum. Eskiden bu tür eski huysuz, "Ah, endişelerin ayrılması" tarzındaki gibi, gerçekten faydalı sınıflara girerdim, ama aslında bunun gerçekten iyi bir çalışma şekli olduğunu düşünüyorum. Yazıda Tailwind CSS'yi gerçekten sevdiğimden bahsetmiştim. İşe yaradığını düşünüyorum ve ürün yazmak için kullanmayı gerçekten seviyorum çünkü gerçekten hızlı bir şekilde bir şeyler ortaya koyabiliyorum. Ama bence biraz fazla ileri gidiyor, öyle değil Tailwind, oysa bir sınıfa tek bir kural uygulamanın ötesine geçtiğinde yağmur yağdırmayı seviyorum. Bence bu kadar. Öyle mi?

Drew: Evet, evet, makalede tasarım belirteçleri hakkında çok konuşuyorsun, üçüncü bölümde Jina Anne ile Smashing Podcast'te konuştuğumuz bir şeydi, sanırım öyleydi. Bu yüzden tasarım belirteçleri gerçekten temel bir özellik gibi görünüyor.

Andy: Evet. Tanrım, evet. Jina'nın Lightning Design System işini yaptığı zamanı çok iyi hatırlıyorum çünkü o sırada bir tasarım sistemi ya da bir tasarım sistemine benzeyen bir şey inşa ediyordum ve bunun için yönetici onayını almak için mücadele ediyorduk. Lightning Design System çıktığında, kelimenin tam anlamıyla onlara link ardına link gönderdim ve “Yaptığımız şey bu. Bir tasarım sistemi kuruyoruz. Salesforce şu anda bunu bunun için kullanıyor.” O zamanki çalışmasının aslında kapıdan bir şeyler almama yardım ettiğini hatırlıyorum.

Andy: O zaman tasarım belirteçleri, bu kuralları uygulamanın gerçekten iyi bir yolu olarak hep aklımda kaldı. Meslek olarak bir tasarımcı olduğum için, bu organizasyonun ve tek bir gerçek kaynağı oluşturma ve organize etme yeteneğinin gerçekten yararlı olduğunu görebiliyorum çünkü dijital tasarımda, özellikle Adobe'de gerçekten sahip olmadığımız bir şey. Photoshop ve benzeri şeylerle çalışma çağında bu lüksümüz yoktu. Pantone Book ile basmıştık ama dükkanın her yerinde rastgele onaltılı kodlarla dijital olarak elimizde yoktu.

Andy: Yani bu harika. Bu kontrol seviyesini seviyorum. Aslında bunun yaratıcılığa yardımcı olduğunu düşünüyorum çünkü artık önemsiz şeyler hakkında düşünmüyorsunuz, sadece onunla ne yaptığınızı düşünüyorsunuz.

Drew: Bu tasarım belirteçlerinin uygulanması özellikle yaklaşım açısından önemli mi? Her zaman CSS özel özellikleri mi?

Andy: Bence bu CUBE ile ilgili gerçekten önemli bir nokta. Aldığım yanıtlardan bazıları, insanlar bununla biraz mücadele etti. İçinde teknolojiden hiç bahsedilmiyor. Tutarlı olan tek teknoloji CSS'dir. Nasıl istersen öyle yapabilirsin. Tüm bunları, insanların şu anda yaptığı CSS ve JS şeyleriyle ya da sadece Vanilla CSS ile yapabilirsiniz. Sass ile yapabilirsin. Sass ile yapıyorum. Daha az, eğer hala yaptığın şey buysa. Tüm bu mevcut teknolojiler, CSS sonrası, tüm bu şeyler. Nasıl istersen öyle yapabilirsin, önemli değil.

Andy: Buradaki fikir şu ki, bu tür yapıları takip edersen, iyi olacaksın. Arkasındaki fikir bu. Bazı metodolojiler gibi çok gevşek ve katı değil. Bunu özellikle BEM'de gördüm, insanlar artık sorunu çözmüyormuşsunuz gibi BEM ilkelerine gerçekten yerleşiyorlar. Bence esnek olmalısın. Geçen yıl bu konuşmada söyledim. “Silahlarınıza çok sıkı sarılırsanız, aslında uzun vadede kendinize sorun yaratabilirsiniz çünkü belirli bir yolu dener ve izlersiniz ve artık işe yaramadığını bilirsiniz” dedim. Her zaman esnek olmalı ve harfi harfine çalışmak yerine bir sistemle çalışmalısınız.

Drew: Yani B, B Blok. Bu fikirden bahsettiniz, blok seviyesine indiğiniz zaman, her şeyin çoğunun yerinde olması gerektiği ve daha sonra blok seviyesindeki stilin gerçekten sadece belirli bir bileşenin gerçek ayrıntılarıyla gerçekten ilgili olduğu fikrinden bahsettiniz. Genel olarak, bir blok kavramı, insanların aşina olacağı şeye benzer mi?

Andy: Ah, kesinlikle, evet. Yani BEM bileşeninizi hayal edin ve tüm görsel öğeleri çıkarın ve aslında size blok kalan şey budur. Bu metodolojiyi ilk düşünmeye başladığımda ifade etmekte zorlandığım şey buydu. Bir blok aslında gerçekten bir C'dir, bu bir kompozisyon, ama bu onu gerçekten zorlaştırıyor çünkü orada özyinelemeli bölgeye giriyorsunuz ve bence insanların beyinleri patlayacak. Ama aslında bir blok budur, aslında başka bir kompozisyon katmanıdır, ancak daha çok bir tür katı bağlamdır, yani kartınız, düğmeniz, atlıkarıncanız, yapmayı sevdiğiniz şey buysa ve tüm bu tür şeyler.

Andy: Bu belirli bir şey, bir bileşen gibi ve sonra onun içinde takip etmesi için belirli kurallar belirliyorsun, gerisini gerçekten görmezden geliyorsun yani öyle değilsin… Bloklara belirteçler uygulayabilirsin ve ben bunu yapıyorum yine de, ama gerçekten daha çok düzen odaklı, onlarla çalıştığım kadarıyla bir blok ya da en azından belirteci alıp belirli bir şekilde, bir düğmenin üzerine gelme durumu gibi, bunun gibi şeyler. Yani gerçekten onlara indiğinizde bloğunuz küçücük olmalı, gerçekten fazla bir şey yapmamalılar.

Drew: Yani bir köprü kadar küçük olabilir.

Andy: Evet.

Drew: Ama aynı zamanda diğer blokların bileşik bir koleksiyonu da olabilir mi?

Andy: Evet. Modül gibi bir şey. Bunu kesinlikle yapabilirsin. Çünkü, yine, bu onun bir tür kompozisyon yönüne geri döner, içine giren her şeyin önemli olmaması gerektiğidir. Bunun iyi bir örneği kart gibidir. Yani bir kartın içeriği, örneğin bir başlık, bir özet ve bir düğme gibidir. Gerçekten bu üç öğeyi özellikle hedeflememelisiniz. “Bak, kendini içerikte bulan her şey, orada bazı akış kuralları var ve bir çeşit kompozisyon düzeni kuralı var” demelisiniz ve o zaman oraya ne koyduğunuz önemli değil. Bu içerik olayına bir resim koymak istediğinize karar verebilirsiniz ve bu işe yaramalı, iyi görünmelidir.

Andy: CSS ile çalışmanın bütün amacı bu. CSS ile çalışmanın çok bağışlayıcı bir yolu. Daha az katı davranarak hayatınızı çok daha kolay hale getiriyorsunuz çünkü bir şeyler yanlışlıkla kendini bir şeyin içinde bulduğunda, ki öyle olacak, şeyler hakkında daha spesifik olsaydınız, olabileceği gibi korkunç görünmüyor, benim yaptığım şey bu. kurmak.

Drew: CSS'imde kesinlikle çok fazla bağışlanmaya ihtiyacım var!

Andy: Yaptığını biliyorum!

Drew: Şerefe! Yani bu B. Son şey E: E İstisnadır. Şimdi hata mesajlarından bahsetmiyoruz, değil mi?

Andy: Hayır, hayır. Bu bir tür-

Drew: JavaScript istisnalarından bahsetmiyoruz.

Andy: Evet, evet. Bu noktada bunların hiçbiri olmamalı. Yine de ummamalıyım, yoksa o noktada gerçekten ormandasın: Sana yardım edebileceğimi sanmıyorum! Bunun tüm fikri… yani bloğunuzla bağlamı yarattınız ve tam olarak bir istisna, kuralın bir istisnası gibi: yani ters çevrilmiş bir kart veya hayalet bir düğme olabilir. Yani bir kenarlığı ve şeffaf bir arka planı olan düğmeleri biliyor musunuz? Bu bir istisna olur, çünkü bir düğmenin muhtemelen düz bir arka plan rengi ve ardından etiket rengi vardır. Yani bir çeşit farklı varyasyon durumu yaratıyor.

Andy: Bunu sınıflar yerine veri öznitelikleri ile yapmamın nedeni ve bunun nedeni şudur: a) Bence bir ayrım yapmanın güzel olduğunu düşünüyorum. Bu nedenle, çok sayıda HTML'yi tararken, verileri görebilir, bir şeyi tire ile işaretleyebilirsiniz, "Doğru, tamam, bu öğede kesinlikle bir şeyler değişti" diyorsunuz. Diğer bir şey ise, JavaScript'e bu duruma erişim izni vermenin çok güzel ve bunun tersi de geçerlidir. Bu yüzden, JavaScript'te veri öznitelikleriyle durumu uygulamayı gerçekten seviyorum. Bence esas olarak bunun için varlar, bir tür iletişim katmanı. Aralarındaki uyum gerçekten iyi çalışıyor gibi görünüyor.

Andy: İyi bir örnek, diyelim ki bir durum mesajınız var ve ardından JavaScript veri durumu ekleyecek ya başarı, hata ya da bilgi ya da başka bir şey. Ardından, CSS'deki istisna stillerinizle buna bağlanabilirsiniz. Yani bunun durum bileşeninin bir istisnası olduğunu ve varsayılan durumuna aykırı olduğunu biliyorsunuz. Yani bu, şeylerle çalışmanın gerçekten kullanışlı bir yolu. Her iki uçta da tahmin edilebilir: CSS tarafında tahmin edilebilir ve JavaScript tarafında da tahmin edilebilir.

Drew: Sanırım sınıf adlarının size vermediği bir şeyin bir özellik ve değer olması oldukça güzel. Öyleyse, durum gibi bir şeye sahip olmak istiyorsanız ve bu ya başarı ya da başarısızlık ya da uyarı ya da sizde ne olabilir, özellikle bu durum özelliğini ele alabilir ve değerini çevirebilirsiniz. Oysa büyük ve uzun bir sınıf adları listesiyle, örneğin JavaScript'te bunu manipüle ediyorsanız, bunların her birine bakmanız ve oraya şu iş mantığını eklemeniz gerekir, "Ben yalnızca ayarlayabilirim. bunlardan biri" ve bu sınıflardan ikisi aynı öğeye uygulanırsa ne olur? Bunu bir data özelliği ile elde edemezsiniz, sadece bir değeri vardır.

Andy: Evet. Bunu söylemenin iyi bir yolu, evet. Böyle çalışmanın çok faydalı olduğunu gördüm.

Drew: Bu oldukça ilginç. Bu yaklaşımı benimseyen başka metodolojiler gördüğümü sanmıyorum. Bunu yapmak tamamen CUBE'a özgü mü?

Andy: Olabilir. Yapmam gereken diğer şeylere pek dikkat etmiyorum. Muhtemelen bunu başka biri yapıyor. Size şimdi söyleyeceğim, bu işin en tartışmalı yönü oldu. Bazı insanlar veri özniteliklerini kullanma fikrinden gerçekten hoşlanmadı. Mesele şu ki ve nasıl cevap vereceğim, istediğini yap. Size bir şeyleri belirli bir şekilde yapmanızı söylemiyoruz, bu sadece öneriler. Değiştiriciler gibi CSS sınıflarında istisnalar yapmak istiyorsanız, kendinizi nakavt edin. CUBE polisi gelip kapınızı çalmayacak. Kesinlikle iyi.

Andy: CUBE olayı düşünen bir şeydir, bir yapıdır. Bu yapıyı istediğiniz şekilde, istediğiniz aletle veya istediğiniz teknolojiyle uygularsınız. İşleri tutarlı tuttuğunuz sürece, önemli olan bu.

Drew: Yani saf KÜP diye bir şey yok mu?

Andy: Yazma şeklim tamamen KÜP, Drew. Diğer herkes sadece bir sahte, bu sadece zayıf bir taklit.

Drew: Senden başka kimse "Bu CUBE ders kitabı değil" diyemez.

Andy: Hayır, bu kadar. Kimse buna gerçekten itiraz edemez, değil mi? Yani, evet, bununla gideceğim. Sana biraz nüfuz falan veriyor, sanırım, onun gibi bir şey.

Drew: CUBE yaklaşımını diğer metodolojilerle karıştırıp eşleştirebilir misiniz? BEM parçalarını kullanabilir misin?

Andy: Evet, sanırım öyle. Biraz düşündüm çünkü yakında üzerinde daha fazla şey yapacağım çünkü oldukça popüler hale geldi, bu yüzden insanlar daha fazla iş isteyecek. Bakacağım şeylerden biri, var olan bir şeyle CUBE metodolojisini kullanarak nasıl yaklaşılacağıdır.

Andy: Yani ölçeğin iki zıt ucu var. İnsanların sorduğu iyi bir soru şudur: "Bu, her düzende, diğer şeylerde nasıl çalışır?" Ben, temelde, her düzen C'dir. Her düzen budur, kompozisyon katmanıdır. Sonra başka biri sordu, "Peki, Brad Frost'un yaptığı şeyler gibi Atomik Web Tasarımı gibi bir şeyle bu nasıl çalışır? Sanki, o parçaları kırabilir ve her seviyede uygulayabilirsiniz. Atomik Tasarım, mikro ayrıntıya kadar iner. Bunu kullanmaya soyutlamak, doğru, tamam, peki bunu yardımcı programlarla uygulayabilirim, yani moleküller, sanırım. Bunu yardımcı programlarla uygulayabilirim ve zaten bildiklerinizi bu biraz farklı çalışma yapısına çevirir.

Andy: Gerçekten, birçok şeyin yeniden adlandırılması. Burada hiçbir şey icat etmedim, sadece bir nevi, dediğim gibi, sadece sevdiğim şeyleri çaldım. Atomik Tasarımla ilgili bazı şeylerin düşünülme şeklini seviyorum. Bu gerçekten akıllıca bir iş. Ve BEM. Harry'nin yaptığı şeyler, Ters Üçgen CSS, bunun gerçekten harika olduğunu düşündüm. Bu yüzden, her birinden sevdiğim çentik parçaları aldım ve hepsini bir şekilde bu diğer melez şeyde birleştirdim, yaklaşım. Daha fazlası gelecek bence.

Drew: CUBE yaklaşımı, halihazırda CSS'si olan mevcut projelere uygulanabilir mi yoksa gerçekten yeni bir projeye başlamanız gereken bir şey mi?

Andy: Bu çok şeye bağlı. Öyleyse, bir önyükleme işiniz varsa ve bu, daha önce kesinlikle dahil olduğum binlerce satırlık özel CSS'ye sahipse, o zaman bir şişe su ile yangını söndürmeye çalışıyor olabilirsiniz. puan. 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? Bu ne hakkında?

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?

Duru: Evet.

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. It is what it is. 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: Biraz farklı bir şey yapmayı ve sahip olduğum bilgiyi uygulamayı ve aslında bunu insanlarla paylaşmayı hayal ettim. Her zaman çok açık ve paylaşımcı oldum ve bunu resmileştirmek istedim. Bu yüzden öğreticiler yazmak için Piccalilli'yi yarattım, ancak esas olarak ürettiğim kurslar için: bunlar ana et ve patatesler. Ve bir de haber bülteni var ki... insanlar bültenden gerçekten keyif alıyorlar çünkü her hafta internette bulduğum harika şeyleri paylaşıyorum. İşin bel kemiği budur. Gerçekten iyi gidiyor. Sanırım yıllar geçtikçe kendimi daha fazla tam zamanlı çalışırken görmek istiyorum.

Drew: Peki Piccalilli için sırada ne var? Çıktığın bir şey var mı?

Andy: Kapıyı açtığın için teşekkürler Drew! Bu kayıt sona erdiğinde, ilk kurs canlı olacak: Sıfırdan Eleveny Öğrenin ve işte burada bir Gatsby web sitesi oluşturmayı öğreniyoruz! Hayır, bir Eleventy sitesini nasıl oluşturacağınızı öğreniyorsunuz. Yani tamamen boş bir dizinle başlıyorsunuz, içinde hiçbir şey yok, boş ve sonunda bu gerçekten güzel görünümlü ajans sitesiyle bitireceksiniz. İçinde her türlü şeyi öğreniyoruz. Eleventy ile gerçekten şehre nasıl gideceğinizi öğreniyorsunuz. Uzak verileri yerlerden çekiyoruz. Bunun için gerçekten güzel bir ön uç oluşturmak için CUBE CSS kullanıyoruz.

Andy: Jamstack'e girmek ve statik site oluşturuculara girmek veya sadece güzel bir web sitesinin nasıl oluşturulacağını öğrenmek istiyorsanız, umarım bunun için gerçekten kullanışlı bir kurstur. Şu anda konuştuğumuz gibi hayatının bir inçinde düzenleniyor. Güzel olacak, umarım ve faydalı olur. Ama bu, son birkaç yıldır yaptığım birçok şeyin birikimi. Bu yüzden eğlenceli olmalı.

Andy: Satın al, ben de bir indirim kodu yapayım, smashingpod'u %40 indirimle yap ve çıktığında alabilirsin.

Drew: İnanılmaz. Bunu bağlayacağız. Piccalilli'yi güvenilir bir şekilde nasıl heceleyeceğinizi henüz bulamadınız mı?

Andy: ShopTalk Show'da Chris ve Dave ile birlikteydim ve orada dedim ki, "Beni işe almak istediğiniz bir şey varsa, o da Piccalilli'yi ilk seferde hiç düşünmeden elle yazmaktır," çünkü ben Bu kelimeyi o kadar çok yazdım ki, tam olarak nasıl heceleyeceğimi biliyorum. Yani sorunuzun cevabı evet.

Drew: Hâlâ mücadele ediyorum, sana o kadarını anlatacağım!

Andy: Zor. Aman Tanrım. Tamamen empati kuruyorum. Nasıl hecelendiğini öğrenmem uzun zaman aldı ama kelime dağarcığımızdaki o kelimelerden biri. Bu yıl yazım hatası yapmadan gerekli hecelemeye çalışıyorum!

Drew: Yani CUBE CSS hakkında her şeyi öğreniyorum. Son zamanlarda ne öğreniyorsun, Andy?

Andy: Biliyor musun? Bu seni şaşırtacak, Drew. MySQL, son zamanlarda öğrendiğim şey. Yani, temel olarak, Piccalilli tamamen kendi kendine yayınlanır. Bu bir Eleventy sitesi ama arkasında bir API var ve bunun arkasında bir MySQL veritabanı var. İnsanlara satın aldıkları içeriği veren şeyler oldukça yoğun sorgulama gerektirir. Bu yüzden biraz MySQL'e gerçekten düzgün bir şekilde yatırım yaptım… özellikle birleştirmeler arasındaki fark, ki aslında her bir birleştirme türü arasında bir fark olduğunu fark etmedim. Bu gerçekten faydalı oldu ve veri tabanı ile oldukça hızlı etkileşimler sağladı.

Andy: Ben Front-End Challenges Club adında bir şeyi çalıştırırdım ve onu ilk başlattığımda çöktü ve kendi kendine öldü çünkü MySQL en hafif tabirle kalitesizdi. Bu yüzden gerçekten bunu nasıl yapacağımı öğreniyorum çünkü ben bir arka uç insanı değilim, ben bir piksel iticiyim. Yani kesinlikle benim görev alanımda değil. Bu daha çok senin ormanın boynu, değil mi? Bunu gerçekten harika buluyorum, MySQL. Aslında yazmayı çok seviyorum. Gerçekten güzel, öğretici bir dil, değil mi?

Drew: Öyle, harika. SQL'i okulda öğrendim.

Andy: Vay!

Drew: Artık 20 yıl öncesinden bahsediyoruz.

Andy: O günlerde bilgisayarları var mıydı?

Drew: Yaptılar, evet. Rüzgar-

Andy: Bunu elle mi yazmak zorundaydın?

Drew: Onları sarmamız gerekiyordu! Yaptık. Ama size söylüyorum, bir geliştirici için bu, çarpım tablosunu öğrenmeye benzer: Biraz angarya gibi görünen ama bir kez akıcı olduğunuzda, tekrar tekrar yararlı hale gelen şeylerden biri.

Andy: Evet. Kesinlikle. Gerçekten somut farklar da var. Hızdaki farkı gerçekten görüyorsunuz. Node ile çalışmayı gerçekten seviyorum çünkü bu gerçekten hızlı ama Node ve MySQL sadece… çok yaygın bir seçim değil, ama bence oldukça iyi bir seçim. Bence gerçekten çok iyi çalışıyor. Bu yüzden mutluyum. Bildiğiniz gibi PHP yazmayı sevmiyorum. Yani bu asla bir seçenek olmayacak.

Drew: Sevgili dinleyici, Andy'den daha fazlasını duymak istiyorsanız, onu hankchizljaw'da olduğu Twitter'da takip edebilirsiniz. Piccalilli'yi piccalil.li adresinde bulabilirsiniz, burada CUBE CSS'yi açıklayan makaleyi de bulacaksınız ve elbette tüm bunlara bağlantılarını da gösteri notlarında ekleyeceğiz.

Drew: Bugün bize katıldığın için teşekkürler Andy. Ayrılık sözleriniz oldu mu?

Andy: Güvende ol ve maskeni tak.