Chris Ferdinandi ile Çarpıcı Podcast Bölüm 21: Modern En İyi Uygulamalar Web İçin Kötü mü?

Bugün, modern en iyi uygulamaların web için kötü olup olmadığını soruyoruz. Modern çerçeveler bizi yanlış yola mı götürüyor? Öğrenmek için Yalın Web uzmanı Chris Ferdinandi ile konuşuyorum.

Notları göster

• Podcast için bağlantılar ve notlar içeren Chris' sayfası
• Yalın Web kitabı
• İnternette Chris Ferdinandi
• Twitter'da Chris
• Vanilya JavaScript Podcast'i

Haftalık güncelleme

• “Tasarım Tel Çerçevelerini Erişilebilir HTML/CSS'ye Çevirme”
  Harris Schneiderman tarafından
• “Electron ve Vue ile Masaüstü Uygulamaları Oluşturma”
  Timi Omoyeni tarafından
• “Okunabilirliği Artırmak İçin Modern CSS Teknikleri”
  Edoardo Cavazza tarafından
• “Tarz Bileşenleri React'te Nasıl Kullanılır”
  Adebiyi Adedotun Lukman
• “Sketch ile Porsche 911 Nasıl Oluşturulur”
  tarafından Nikola Lazareviç

Transcript

Drew McLellan: Vanilla JS Pocket Guide Series'in yazarı, Vanilla JS Academy Eğitim Programının yaratıcısı ve Vanilla JS Podcast'in sunucusu. Bir İpuçları bülteni geliştirdi, hafta içi her gün yaklaşık 10.000 geliştirici tarafından okunuyor. Chobani ve The Boston Globe gibi kuruluşlarda geliştiricilere eğitim verdi. JavaScript eklentileri, Apple ve Harvard Business School gibi kuruluşlar tarafından kullanılmıştır. En önemlisi, insanların Vanilla JavaScript'i öğrenmelerine yardımcı olmayı seviyor. Yani bir çerçeve yerine Vanilla JavaScript'i seçmeyi tercih ettiğini biliyoruz, ancak bir keresinde bir polis kadrosunda suçu işleme olasılığı en düşük kişi olarak seçildiğini biliyor muydunuz? Smashing arkadaşlarım, lütfen Chris Ferdinandi'ye hoş geldiniz. Merhaba Chris. Nasılsınız?

Chris Ferdinandi: Oh, bayılıyorum. Bana sahip olduğun için teşekkürler.

Drew: Bugün seninle bu Yalın Web kavramı hakkında konuşmak istedim, ki bu senin için biraz tutkulu, değil mi?

Chris: Evet, çok fazla.

Drew: Neden bizim için sahneyi hazırlamıyorsun? Yalın Web hakkında konuştuğumuzda, çözmeye çalıştığımız sorun nedir?

Chris: Evet, harika bir soru. Tüm dinleyiciler için bir uyarı olarak, bu bölüm yaşlı bir adamın buluta bağırmasına neden olabilir. Bundan kaçınmaya çalışacağım. Bugün web için nasıl oluşturduğumuza baktığımda, biraz fazla mühendislik ürünü bir karmaşa gibi geliyor. Bugün en iyi uygulamalar olarak düşündüğümüz pek çok şeyin aslında web'i daha da kötüleştirebileceğine inanmaya başladım.

Chris: Yalın Web, basitliğe, performansa ve geliştirici deneyimine odaklanan bir web geliştirme yaklaşımıdır... Üzgünüm, geliştirici deneyimi değil. Geliştirici deneyimi yerine kullanıcı deneyimi ve ekip perspektifinden bir şeyler inşa etme kolaylığı, bence bugün en çok odaklandığımız nokta bu ve muhtemelen konuşmamıza da dahil olacağız.

Chris: Aslında, geliştirici deneyimini iyileştirdiğini düşündüğümüz bu şeylerin çoğunun, geliştiricilerin bir alt kümesi için bunu yaptığını, ancak inşa ettiğiniz şey üzerinde çalışan herkes için gerekli olmadığını keşfettim. Dolayısıyla bununla ilgili de inceleyebileceğimiz bir sürü sorun var. Ama gerçekten, Yalın Web, kullanıcı için basitlik ve performansa odaklanmak ve gerçekten bizim yaptığımız şeyleri kullanan insanlara, onu yapan insanlara öncelik vermek veya odaklamakla ilgilidir.

Drew: Web bir geliştirme platformu olarak olgunlaştıkça, uzmanlaşmaya doğru giderek artan bir yönelim var gibi görünüyor.

Chris: Evet.

Drew: Eskiden Full Stack'i ele alan ve ardından ön uç ve arka uç olarak ikiye ayrılan insanlar. Ve sonra bu ön uç, CSS veya JavaScript geliştirme yapan kişilere bölündü. Ve sonra giderek JavaScript içinde, daha özel hale geliyor. Birisi kendilerini bir React geliştiricisi veya bir Angular geliştiricisi olarak düşünebilir ve pazarlayabilir ve tüm kimlikleri ve görünümleri, oldukça yetenekli oldukları belirli bir çerçeveye dayanmaktadır. Web'deki çalışmalarımızın özü olan bu bağımlılık çerçevelere mi, kötü bir şey mi?

Chris: Bu nüanslı. Evet, her zaman kampında çok güçlüydüm. Genel olarak düşünüyorum, hala evet gibi hissediyorum, genel olarak çerçevelere ve araçlara sahip bir endüstri olarak takıntımız gerçekten potansiyel olarak biraz zararımıza. Çerçevelerin doğal olarak kötü olduğunu düşünmüyorum. Çok dar bir kullanım durumu alt kümesi için faydalı olduklarını düşünüyorum. Ve sonunda, sizin veya projeniz için gerçekten en iyi seçim olmadıkları pek çok durum da dahil olmak üzere, onları neredeyse her şey için kullanıyoruz.

Chris: Bugün web'de sahip olduğumuz birçok sorunu düşündüğümde, bu sorunların özü gerçekten çerçevelere aşırı güvenimizle başlıyor. Bundan sonra gelen her şey birçok yöndendir, çünkü web'e sadece genel olarak JavaScript olan çerçeveleri atmıyoruz. Bunu insanlara JavaScript yazmayı ve kullanmayı profesyonel olarak öğreten biri olarak söylüyorum. Paramı böyle kazanıyorum. Ve burada çok fazla JavaScript kullandığımızı düşünüyorum, ki bu bazen biraz garip bir şey.

Drew: Büyük çerçeveler filizlenmeden önce, jQuery veya her neyse, kullanıcı arayüzleri ve şeyler inşa ederdik. Sonra çerçeveler ortaya çıktı ve bize bu durum tabanlı kullanıcı arayüzü konseptinden daha fazlasını verdiler.

Chris: Evet.

Drew: Şimdi, yerine geçmeniz gereken oldukça karmaşık bir mühendislik parçası. Daha az JavaScript ile çalışmak, böyle bir şeyi kullanmayı dışlar mı, yoksa bunu kendiniz mi yeniden uygulamanız gerekiyor? Sadece yüklü bir kazan plakası mı oluşturuyorsunuz?

Chris: Bunların çoğu ne yaptığınıza bağlı. Değişmeyen bir arayüzünüz varsa, durum tabanlı bir kullanıcı arayüzü oluşturabilirsiniz… Bilmiyorum, belki bir düzine kadar kod satırı. Değişmeyen bir arayüzünüz varsa, dürüstçe muhtemelen durum tabanlı kullanıcı arayüzü söyleyebilirim. Bu mutlaka doğru bir yaklaşım değildir. Muhtemelen bunun yerine yapabileceğiniz başka şeyler vardır. Statik site oluşturucuları, önceden oluşturulmuş bazı işaretlemeleri, hatta eski tarz bir WordPress veya PHP tabanlı siteyi düşünün.

Chris: Ama bunun ilginçleşmeye başladığı yer, daha dinamik ve etkileşimli arayüzlere girdiğiniz zamandır. Sadece uygulamalar değil. İnsanların web siteleri ve uygulamalar arasında bu çizgiyi çizmeyi sevdiklerini biliyorum ve bence ikisi arasında garip bir karışım var ve çizgi her zaman o kadar net değil. Daha fazla kullanıcı bir şeyler yapmaya başladığınızda, bir şeyler değişir. Durum tabanlı kullanıcı arayüzü biraz daha önemli hale geliyor. Ancak bunun gerçekleşmesi için hala tonlarca koda ihtiyacınız yok.

Chris: Kesinlikle harika mühendislik parçaları olan React veya Vue gibi bir şeye bakıyorum. Bunlar üzerinde çalışan insanlardan uzaklaşmak istemiyorum. Sonunda, bu şeylerin kaputun altında nasıl çalıştığını daha iyi anlamak için kendi mini çerçevemi oluşturan bir öğrenme alıştırması olarak bitirdim. Tüm farklı hareketli parçaları hesaba katmak gerçekten zor. Bu nedenle, bu araçları yapan ve üzerinde çalışan insanlara büyük saygı duyuyorum. Ancak React ve Vue, küçültme ve gzip işleminden sonra yaklaşık 30 kilobayttır. Yani onları bir kez açtığınızda, bundan çok daha büyükler.

Chris: Tamamı değil ama bu ağırlığın önemli bir kısmı sanal DOM denen şeye ayrılmış. Benzer API'leri veya yaklaşımları kullanan alternatifler var. React için, 30 yerine 2.5 kilobayt veya yaklaşık 3 kilobayt olan Preact'iniz var. Boyutun onda biri. Vue için bunun yerine yaklaşık 7 kilobayt olan Alpine JS'niz var. Yine de, önemli ölçüde daha küçük. Onlarla ağabeyi meslektaşları arasındaki en büyük fark, sanal DOM'u atmış olmalarıdır. Bir veya iki yöntemi bırakabilirler. Ancak genel olarak, kodla çalışma biçiminde aynı yaklaşım ve aynı tür API'dir ve önemli ölçüde daha küçüktürler.

Chris: Bence kullandığımız birçok araç, yapmaya çalıştığımız şeyler için potansiyel olarak aşırı güçlü. Durum tabanlı bir kullanıcı arayüzüne ihtiyacınız varsa ve reaktif verilere ve bu dinamik arayüzlere ihtiyacınız varsa, bu harika. Sanırım bugün hakkında konuşmaya çalıştığım en büyük şeylerden biri... asla alet kullanmamak. Benim için Vanilla JS, her kod satırını ve yaptığınız her projeyi el yazısıyla yazmıyorsunuz. Bu delilik. Bunu yapamadım, yapmıyorum. Ancak kullandığımız araçlar konusunda daha seçici davranıyoruz. Her zaman çok amaçlı aleti, içinde tüm bunları barındıran İsviçre Çakısı'nı tercih ederiz. Ve bazen, gerçekten ihtiyacınız olan tek şey bir makastır. Diğer tüm şeylere ihtiyacın yok, ama yine de bizde var.

Chris: Bu gerçekten uzun bir yol... Sorunuza cevap verdiğim için üzgünüm. Bu, bazen sizin yazabileceğinizden veya kendiniz yazmak isteyeceğinizden daha fazla koddur, ancak gerektirdiğini düşündüğümüz kadar kod değildir. Bir çerçeveye ihtiyacınız olmadığını söylediğimde, "Bir çerçeve kullanmıyorsanız, temel olarak kendi çerçevenizi yazıyorsunuz" şeklindeki bu fikir etrafında çok fazla geri dönüş alıyorum. O zaman bu kendi sorunlarıyla birlikte gelir. Bence React veya Vue kullanmakla kendi çerçevenizi yazmak arasında bir yer var ve belki biraz daha küçük bir şey seçmektir. Yapmaya çalıştığınız şeye bağlı olarak, bazen kendi çerçevenizi yazmanın gerçekten doğru çağrı olmasının nedenleri vardır. Hepsi çok akıcı ve öznel.

Drew: Bir öğrenme alıştırması olarak kendi devlet temelli çerçevenizi uygulamanız oldukça ilginç. Hatırlıyorum, eskiden ne zaman bir kütüphaneye falan uzansam, kendim uygulayabileceğimi düşünmek hoşuma giderdi diye düşünürdüm.

Chris: Tabii, tabii.

Drew: Ama kütüphaneye ulaşmak beni bunu yapma zahmetinden kurtardı. Bu kodu kendim yazmam gerekseydi, bunu yapmak için hangi yaklaşımı kullanacağımı biliyordum. Ve bu, jQuery ve benzeri şeyleri kullanmaya kadar doğruydu. Bu günlerde, kendi Vue veya React versiyonumu yazmam gerekseydi, o kütüphanede, tüm bu kodlarda şu anda neler olduğu hakkında neredeyse hiçbir fikrim olmadığını düşünüyorum.

Drew: Tanıdık olmayan bizler için, Preact gibi bir şey sanal DOM'yi bırakıp her şeyi çok daha küçük hale getirdiğinde, bu sanal DOM bize ne veriyor?

Chris: Bu soruyu yanıtlamak için biraz geriye gitmek istiyorum. Çerçevelerin ve diğer devlet tabanlı kitaplıkların size sunduğu en güzel şeylerden biri DOM farkıdır. Kullanıcı arayüzünü gerçekten o kadar güncellemiyorsanız, “İşte, işaretlemenin nasıl görünmesi gerektiğine dair bir dize. HTML'de, tüm bu işaretlemeyi bu öğeye koyacağım." Bir şeyi değiştirmeniz gerektiğinde, tekrar yaparsınız. Bu, tarayıcılar için biraz pahalıdır, çünkü yeniden boyamayı tetikler.

Chris: Ama potansiyel olarak bundan daha önemli olduğunu düşünüyorum, bunu yapmanın sorunlarından biri, orada herhangi bir etkileşimli öğeye, bir form alanına, birinin odaklandığı bir bağlantıya sahip olmanızdır. Bu odak kaybolur çünkü öğe… benzer görünen yeni bir şeye sahip olsanız bile, aynı gerçek öğe değildir. Dolayısıyla odak kaybolursa, ekran okuyucu kullanan kişilerde kafa karışıklığı yaratabilir. Bununla ilgili bir sürü sorun var.

Chris: Ağırlığına değecek herhangi bir eyalet tabanlı UI, DOM farkı için bazılarını uygulayacak, burada şöyle diyorlar: “Kullanıcı arayüzünün nasıl görünmesi gerektiği. DOM'da şu anda böyle görünüyor. Farklı olan ne?” Ve gidip bu şeyleri değiştirecek. Kullanıcı arayüzünü kendiniz manuel olarak güncellemek için yapacağınız şeyleri etkili bir şekilde yapıyor, ancak bunu sizin için kaputun altında yapıyor. Yani sadece "İşte böyle görünmesini istiyorum" diyebilirsiniz. Ve sonra kütüphane veya çerçeve bunu çözer.

Chris: Preact veya Alpine gibi daha küçük şeyler aslında bunu doğrudan yapıyorlar. Kullanıcı arayüzünün nasıl görünmesi gerektiğine dair sağladığınız dizeyi HTML öğelerine dönüştürüyorlar. Ve sonra her bir öğeyi gerçek DOM'deki karşılık gelen parçasıyla karşılaştırıyorlar. Sonunda, gittikçe büyüyen ve büyüyen UI'ler elde ettikçe, DOM'yi tekrar tekrar sorgulamak pahalı hale geldiğinden, bunun bir performans etkisi olabilir. Bunun bir sorun haline geldiği arabirim türü hakkında bir fikir edinmek istiyorsanız, sağ tıklayın ve Twitter'daki "Favori" düğmesine veya Facebook'taki "Beğen" düğmesine tıklayın ve öğeyi inceleyin. Ve sizi o öğeye götüren div'lerin yuvalanmasına bir göz atın. Çok, çok derin. Sadece o tek tweet için iç içe geçmiş bir düzine kadar div gibi.

Chris: Bu kadar çok katman aşağı inmeye başladığınızda, performansı gerçekten etkilemeye başlar. Sanal DOM'nin yaptığı, her seferinde gerçek DOM'u kontrol etmek yerine, JavaScript'te UI'nin nasıl göründüğüne dair nesne tabanlı bir harita oluşturmaktır. Ardından, mevcut olanı değiştirmek istediğiniz kullanıcı arayüzü için aynı şeyi yapar ve bu ikisini karşılaştırır. Bu, teorik olarak gerçek DOM'da yapmaktan çok daha fazla performans. Değiştirmesi gereken şeylerin bir listesini aldığında, hemen kaçar ve bu değişiklikleri yapar. Ancak DOM'a yalnızca bir kez saldırması gerekir. Her bir öğeyi her seferinde kontrol etmiyor. Twitters veya Facebooks veya QuickBooks gibi arayüzleriniz varsa veya bunun gibi bir şey varsa, sanal DOM muhtemelen çok mantıklıdır.

Chris: Buradaki zorluk… Preact ve React arasındaki fark, siz her şeyi gerçek kod dalgasına açmadan önce 27 kilobayttır. Tek başına ham indirme ve paketi açma ve derleme süresi, bir kullanıcı arayüzündeki ilk yüke biraz gecikme ekleyebilir. Kullanıcılarınız Apple'ın en yeni cihazlarında değilse, bu daha da belirginleşir. Birkaç yıl öncesine ait bir Android cihaz veya özellikli bir telefon bile veya gelişmekte olan ülkelerde insanlarınız varsa, bu gerçekten… başlama zamanı daha yavaştır. Bunun da ötesinde, ekstra soyutlama nedeniyle gerçek etkileşim süresi daha yavaştır.

Chris: Yani sadece siz yüklemiyorsunuz ve hızları da kıyaslanabilir. Birinin yaptığı her mikro etkileşim ve gerçekleşmesi gereken değişiklikler, oradaki tüm bu fazladan kod nedeniyle biraz daha yavaş olabilir. Çok sayıda iç içe öğe ve çok sayıda veri içeren gerçekten çok karmaşık bir kullanıcı arayüzünüz varsa, sanal DOM'nin performansı bu ekstra kod ağırlığından daha ağır basar. Ancak geliştiricilerin çoğunun React veya Vue kullandığını gördüğüm tipik bir uygulama için herhangi bir tipik kullanıcı arayüzü, sanal DOM'den elde ettiğiniz fayda orada değil ve daha iyi durumda olacaklar. Aynı React rahatlığını sürdürmek isteseniz bile Preact kullanın. Boyutunun küçük bir kısmı, tamamen aynı şekilde çalışacak ve daha performanslı olacak. Bu benim tartışmaya meyilli olduğum türden bir şey.

Chris: İş için doğru aleti seçme konusunda daha iyi olmamız gerekiyor. Böyle bir yaklaşımla giderseniz, sanal bir DOM'nin gerçekten anlamlı olduğu bir noktaya gelirseniz, Preact'i React'e taşımak, kendinizinkini almaktan çok daha kolaydır. Durum bu. Bunun için gerçekten endişeleniyorsanız, yerleşik olarak geleceğe yönelik bazı özellikler de alırsınız.

Drew: Bazıları, bu çerçevelerin, Vue, React gibi şeylerin performans için o kadar yüksek düzeyde optimize edildiğini ve orada o kadar çok fayda elde ettiğinizi ve kesinlikle bunu bir paketleyicideki bir paket yöneticisiyle eşleştirerek, " sadece istediğiniz kodu göndererek. Elbette, sadece bunu yaparak zaten çok öndesiniz?

Chris: Evet. katılmıyorum. Bunun dışında ayrıntılı olarak anlatacak pek bir şeyim yok… Sanırım olabilir, ama gerçekten değil. Bir paketleyiciyle bile, yine de o React çekirdeğine ihtiyacınız var. Paketleme ile bile, Preact gibi bir şey kullanmaktan daha büyük olacak.

Chris: Drew, bu soruyu yönelttiğin için gerçekten minnettarım. Çünkü benim kitabım The Lean Web'de bahsettiğim diğer şeylerden biri ve aynı isimdeki konuşmam, bu araçların nasıl olduğu… Örneğin paketlemeden bahsettiniz. Tüm bu JavaScript'i kullanmaktan aldığımız performans düşüşünü aşmak için yaptığımız şeylerden biri, bunu hesaba katmak için ön uca daha da fazla JavaScript atıyoruz. Bunu yapmanın yollarından biri paket yöneticileri ve modül paketleyicileridir.

Chris: Sizin de ima ettiğiniz gibi... bilmeyenleriniz için, bunlar... tüm küçük bireysel JavaScript bitlerinizi tek bir büyük dosyada derleyecek araçlar. Daha yenileri ve daha fazlası… Onlara düşünceli demek istemiyorum. Ancak daha yeni olanlar, gerçekten gerekli olmayan herhangi bir koddan kurtuldukları ağaç sallama adlı bir özelliği kullanacaklar. Bu kodun gerçekte yaptığınız şey için kullanılmayan bazı bağımlılıkları varsa, paketlerinizi mümkün olduğunca küçük yapmak için bu şeylerden bazılarını bırakırlar. Aslında bu korkunç bir fikir değil, ama bu, bağımlılıkların üstüne bağımlılıkların üzerine bu gerçekten hassas bağımlılık kartlarına sahip olduğunuzda, tipik olarak bağımlılık sağlığı dediğim şeyle sonuçlanır.

Chris: İşleminizi kurmak zaman alır. Ve bir NPM kurulumu çalıştıran ve daha sonra bir grup bağımlılığın güncel olmadığını ve hangilerinin düzeltilmesi gerektiğini anlamaya çalışmak için bir saat harcamak zorunda kaldığını keşfeden herhangi biri ve ah, bu aslında bir bağımlılıkta bir bağımlılıktır ve siz yapmazsınız. Gidip kendin tamir etme yeteneğine sahip değilsin. Bu bir bütündür. Belki senin için işe yarar, ama zamanımı bağımlılıklarımı bir araya getirmeye çalışmakla uğraşmadan harcamayı tercih ederim.

Chris: İş akışlarında harcanan zamandan şikayet ettikleri insanlardan tweetler toplamaya başladım. Benim favorilerimden biri olan Brad Frost, birkaç yıl önce, modern JS'de üzerinde durduğunuz şeyin jQuery'de 10 dakikanızı alabileceğine dair iç karartıcı farkındalıktan bahsediyordu. Ben gerçekten bir jQuery hayranı değilim, ancak çerçevelerle çalışmak söz konusu olduğunda bu acıyı hissediyorum.

Chris: Bu araçların çoğuyla ilgili diğer bir konu da kapı bekçileri olmaya başlamalarıdır. Buna gerçekten dalmayı ne kadar isteyip istemediğini bilmiyorum, Drew. Ama JS'ye karşı en büyük itirazlarımdan biri, bir iş akışındaki her şey. Özellikle, “Peki, zaten HTML için JS kullanıyorsak, neden CSS için de kullanmayalım?” demeye başladığınızda. Gerçekten yetenekli birçok insanı geliştirme sürecinden dışlamaya başlıyorsunuz. Bir bütün olarak toplum için proje için gerçekten büyük bir kayıp.

Drew: Pekala, kesinlikle öyleyim… 2020'nin başında React'i almaya başladım ve bunu beceri setime ekledim. Şimdi neredeyse yedi aydır yapıyorum. En az güvendiğim kısımlardan birinin, bir projeyi başlatmak için gerekli araçları ayarlamak olduğunu söylemeliyim.

Drew: Merhaba Dünya'ya bir şey getirmek için çok fazla iş var gibi görünüyor ve onu üretime hazır hale getirmek için bilmeniz gereken daha çok şey var. Bir web geliştiricisi olmayı öğrenmek için 2020'de yapmanız gerekenler olarak öne sürülüyorsa, bu, geliştirmeye başlamayı daha zor hale getirmelidir. Yeni gelen birinin gerçek bir sorunu olacak. Giriş için gerçek bir engel olacak, değil mi?

Chris: Kesinlikle. Buradaki diğer parça, JavaScript geliştiricilerinin her zaman bir kod tabanı üzerinde çalışan veya bu kod tabanına anlamlı bir şekilde katkıda bulunan tek kişi olmadığıdır. JavaScript'i bir kod tabanıyla çalışmak için ne kadar çok bir gereklilik haline getirirsek, bu kişilerin projeye fiilen katılma olasılığı o kadar azalır.

Chris: Bunun hakkında konuşmaktan hoşlandığım bir örnek, son zamanlarda ortaya çıkan WordPress… Bu noktada son zamanlarda söylememeliyim. Şimdi birkaç yıl oldu. Ancak arka uç yığınlarını, doğası gereği kötü bir şey olmayan PHP'den giderek daha fazla JavaScript'e kaydırıyorlar. Yeni editörleri Gutenburg, React üzerine kurulu.

Chris: 2018'de, WordPress'in önde gelen erişilebilirlik danışmanı Rian Rietveld, adını neredeyse kesinlikle kast etmiştim… herkesin önünde görevinden istifa etti ve nedenini gerçekten ayrıntılı bir makaleyle belgeledi. Sorunun özü, onun ve ekibinin, erişilebilir olacağından emin olmak için bu editörü denetlemekle görevlendirilmiş olmasıydı. WordPress artık web'in %30'unu oluşturuyor. Amaçları yayıncılığı demokratikleştirmek, dolayısıyla erişilebilirlik bunun gerçekten önemli bir parçası. Herhangi bir web projesinin önemli bir parçası olmalıdır. Ama özellikle onlar için son derece önemlidir. Ekibinin tüm işi emin olmak… Ekibinin tüm işi bu editörün erişilebilir olmasını sağlamaktı. Ancak ne kendisinin ne de ekibindeki herhangi birinin React deneyimine sahip olmaması ve erişilebilirlik topluluğunda bu deneyime sahip gönüllüler bulamamaları, onun ve ekibinin işlerini yapmasını gerçekten zorlaştırdı.

Chris: Tarihsel olarak, hataları tespit edebilir ve ardından içeri girip düzeltebilirler. Ancak yeni React tabanlı iş akışıyla, hataları tespit etmeye ve ardından biletleri dosyalamaya indirgendi. JavaScript geliştiricilerinin üzerinde çalıştığı diğer tüm özellik geliştirme istekleriyle birlikte bir biriktirme listesine eklendiler. Kolayca düzeltilebilecek birçok şey ilk sürümde yer almadı.

Chris: Mayıs 2019'da, Rian istifa ettikten yaklaşık bir yıl sonra, Gutenburg'da ayrıntılı bir erişilebilirlik denetimi yapıldı. Raporun tamamı 329 sayfaydı. Yalnızca yönetici özeti 34 sayfaydı. Erişilebilirlikle ilgili 91 hatayı oldukça ayrıntılı bir şekilde belgeledi. Bunların çoğu gerçekten… Onlara basit, düşük asılı meyveler demek istemiyorum, ancak birçoğu Rian'ın ekibinin düzeltebileceği temel şeylerdi ve geliştiricilerin özellik geliştirmeye odaklanmasını sağlardı. Sonuç olarak, görünüşe göre bu, özellik geliştirmeye çok zaman harcamak ve bu işi daha sonraya bırakmaktı. Ancak bu ekip proje için çok önemli ve teknik bir seçim yüzünden birden sürecin dışında kaldılar.

Chris: Alex Russell, Chrome ekibinde bir geliştiricidir. Birkaç yıl önce, çerçevelerin saman adam argümanından bahsettiği The Developer Bait ve Switch adlı bu makaleyi yazdı. Bu araçların daha hızlı hareket etmenizi sağladığı fikri ve bu nedenle daha hızlı yineleme yapabilir ve daha iyi deneyimler sunabilirsiniz. Bu fikir, daha iyi bir geliştirici deneyiminin daha iyi bir kullanıcı deneyimi anlamına geldiği fikridir. Bence bu, bu argümanın her zaman insanların inandığı şekilde sonuçlanmadığına dair çok açık bir örnek. Belki bazı insanlar için daha iyi bir deneyim, herkes için değil.

Chris: CSS geliştiricileri, tasarım sistemleri üzerinde çalışan insanlar, başkalarının kullanabileceği araçlar yaratma yetenekleri de bazen bu araç seçenekleriyle sınırlanıyor. Tecrübelerime göre, CSS'de daha iyiydim. Son birkaç yılda çok değişti ve eskisi kadar iyi değilim. Tecrübelerime göre, gerçekten ileri düzey CSS geliştiricileri olan insanlar… ve bunu en gerçek anlamda söylüyorum. CSS üzerinde çalışan kişiler, bir programlama dili üzerinde çalışan uygun web geliştiricileridir. Bu çok özel bir şey ya da çok özel bir şey olabilir. Tecrübelerime göre, bunda son derece iyi olan insanlar JavaScript'te de her zaman çok iyi değiller çünkü sonunda bir şeye gerçekten derinden dalıyorsunuz ve diğer bazı şeylerde biraz kayıyorsunuz. Bu teknolojilerle çalışma yetenekleri de engelleniyor, bu çok kötü çünkü eskiden böyle değildi.

Chris: Yığın daha basit olduğunda, birden çok disiplinden kişilerin geliştirme sürecine katılması daha kolaydı. Bence bu, artık böyle olmadığında hem inşa ettiğimiz şeylere hem de genel olarak topluluğa zarar veriyor.

Drew: Geçenlerde bir projede bazı CSS problemleriyle, iş akışı problemleriyle başa çıkmanın yollarını araştıran bir proje buldum, proje üzerinde birden fazla çalışıyoruz ve paket boyutu artıyor ve eski CSS asla kaldırılmıyor. Bu bir React projesiydi, bu yüzden sahip olduğumuz sorunları çözmek için en iyisinin ne olacağını görmek için JavaScript yaklaşımlarındaki bu CSS'lerden bazılarına bakıyorduk. Çok hızlı bir şekilde ortaya çıkan şey, bunu yapmak için tek bir çözüm olmadığıdır. Bunu yapmanın onlarca farklı yolu var.

Drew: JS'de CSS genel bir yaklaşımdır, ancak bir projeden diğerine geçebilir ve tamamen farklı bir şekilde etkilenir. Bir CSS çalışanı olsanız ve bir projede belirli bir yaklaşımı öğrenmiş olsanız bile, bu beceriler zaten aktarılabilir olmayabilir. JavaScript konusunda özellikle rahat olmayan birinin bunu öğrenmek için nasıl çok fazla zaman harcaması gerektiğini anlamak çok zor.

Chris: Evet. Biraz önce fark ettiğinizi düşündüğüm diğer ilginç şey, bunun hakkında konuştuğumda aldığım en büyük geri itme parçalarından biri, çerçevelerin kuralları zorlaması. Vanilla JavaScript ile gidiyorsunuz, bu yeşil alan-mavi gökyüzünüz var, istediğiniz her şeyi yapabilirsiniz türden bir proje. React ile işleri yapmanın bir React yolu var.

Chris: Ama bulduğum şeylerden biri, Reacty yaklaşımlarının olduğu, ancak React ile bir şeyler yapmanın kesin ve doğru bir yolu olmadığı. İnsanların bu konuda sevdiği şeylerden biri. Biraz daha esnek, isterseniz birkaç farklı şekilde yapabilirsiniz. Vue'da da aynı. Özelliklerinizi doğrudan HTML'de aldığınız ve Vue'nin bunları değiştirdiği HTML tabanlı şeyi kullanabilirsiniz, ancak isterseniz daha JSX benzeri bir şablonlama sözdizimi de kullanabilirsiniz.

Chris: Birden fazla kişinin React'i öğrenirken şikayet ettiğini duydum, en büyük sorunlardan biri Google'ın React'te X'i nasıl yapacağınız ve bu şeyi yapabileceğinizin bir düzine farklı yolunu anlatan bir düzine makale alıyorsunuz. Bu, bir projeye bazı korkuluklar koymadıkları anlamına gelmez. “Bir çerçeve seçtim. Şimdi onunla inşa etme şeklim bu.” Dürüst olmak gerekirse, bunun benim de isteyeceğim bir şey olduğunu bilmiyorum. Bunların sıkıca kapatılmasını isteyeceğinizi sanmıyorum… bazı insanlar istiyor, belki. Ama bunu bir fayda olarak lanse ediyorsanız, bunun insanların bazen iddia ettiği kadar belirgin olduğunu düşünmüyorum.

Chris: Tam orada, artık ihtiyaç duyulmayan CSS'den bahsettiğiniz yerde ilginç bir şeye girdiniz. Bence bu, CSS ve JS gibi bir şeyin yasal olarak ilginç şeylerden biri… veya CSS'nizi JavaScript bileşenlerine bir şekilde bağlamanın size getirebileceği, bu bileşen düşerse, teoride CSS de ortadan kalkar. Bunların çoğu bana mühendislik insanların sorunlarına atılmak gibi geliyor. Değişmez bir şekilde, hala hat boyunca bir yerlerde insanlara bağımlısınız. Bu, bu yaklaşımları asla kullanmayın demek değil, ancak kesinlikle bu sorunu çözmenin tek yolu değiller.

Chris: HTML'nizi denetlemek ve kullanılmayan stilleri CSS ve JavaScript kullanmadan bile çıkarmak için kullanabileceğiniz araçlar var. CSS'yi "eski moda yöntemle" yazabilir ve yine de kullanılmayan stillerin astarını yapabilirsiniz. Size JS benzeri çıktıda bir CSS veren ve bazen CSS ve JS ile aldığınız bu anlamsız insan tarafından okunamayan sınıf adlarını tükürmeden stil sayfanızı küçük tutan CSS yazma yaklaşımları vardır. X2354ABC gibi, ya da sadece ağzından çıkan bu saçma sapan kelimeler gibi.

Chris: Bu, yaşlı adamın bulut gibi şeylere bağırmasına gerçekten girmeye başladığım yer. Burada gerçekten geliştirici yaşımı gösteriyorum. Ama evet, bu şeylerin kötü olması gerekmez ve meşru sorunları çözmek için inşa edilmişlerdir. Bazen biraz… Facebook için yeterince iyiyse, bunlarla olan şeyler bizim için de yeterince iyiymiş gibi hissediyorum. Facebook bu aracı kullanıyor. Eğer gerçek bir mühendislik programıysak… ekip, departman, organizasyon, biz de yapmalıyız. Bunun hakkında düşünmenin doğru yolu olduğunu düşünmüyorum. Bunun nedeni, Facebook'un sizin ilgilenmediğiniz sorunlarla ilgilenmesidir ve bunun tersi de geçerlidir. Üzerinde çalıştıkları şeyin boyutu ve ölçeği farklı ve sorun değil.

Duru: Aynen. CSS ve JavaScript gibi bazı şeylerin neredeyse çoklu dolgu gibi olduğunu görüyorum. Meşru sorunlarımız var, bunu çözmek için bir yola ihtiyacımız var. Teknoloji henüz bize bunu çözmenin bir yolunu sağlamıyor. Belki web platformunun gelişmesini ve bu sorunu çözmeyi beklerken, şu anda JavaScript ile yaptığımız bu şey bir nevi bizi görecek ve sorun olmayacak. Kötü olduğunu biliyoruz. Bunun harika bir çözüm olmadığını biliyoruz, ancak şu anda bize yardımcı oluyor. Ve umarım bir süre sonra onu çekip yerel çözümü kullanabiliriz.

Chris: Bunu gündeme getirmen gerçekten komik. Çünkü kelimenin tam anlamıyla dün gece, Jeremy Keith'in geçen yılki progresif web uygulamaları hakkında bir konuşmasını izliyordum. Ancak birkaç on yıl önce insanları JavaScript kullanmaya nasıl ikna etmeye çalıştığından bahsediyordu. O zamanlar gülünç görünüyor, ancak JavaScript bu yeni şeydi. İnsanlara bu yeni ile fareyle üzerine gelindiğinde bir bağlantının rengini değiştirmek gibi harika şeyleri nasıl yapabileceğinizi gösterdi… Bunun için JavaScript'e ihtiyacınız olması saçma görünüyor, çünkü CSS sizin için bunu yapıyor. Ancak odak niteliği veya özelliği gibi şeyler o sırada mevcut değildi.

Chris: Konuşmada bana gerçekten yankı uyandırdığını düşündüğüm şeylerden biri JavaScript'in birçok yönden ineklerin yollarını açtığıdır. Bu çok esnek ve açık dil, henüz var olmayan özellikleri oluşturmak veya bu özelliklerde cıvatalamak için kullanabiliriz. Ve sonunda, tarayıcılar bu özellikleri yakalar ve daha yerel bir şekilde uygular. Ama zaman alır. Bu konuda söylediklerinizi tamamen anlıyorum. Mükemmel bir çözüm değil, ama şu anda elimizde olan bu.

Chris: Bence çoklu dolgular ile bu çözümlerden bazıları arasındaki en büyük fark, çoklu dolguların sökülmek üzere tasarlanmış olmasıdır. Tarayıcının henüz desteklemediği bir özelliği uygulamak istiyorum, ancak bunun için bir tür belirtim var ve bir çoklu dolgu yazarım… herhangi bir şeyi değiştir. Ancak bu araçlardan bazılarını kullanma yoluna gittiğinizde, onları sökmek, tüm kod tabanınızı yeniden yazmak anlamına gelir. Bu gerçekten pahalı ve sorunlu. Bu, onları asla kullanmayın demek değil, ancak daha sonra kolayca çıkarılabilen toplama araçları üzerinde düşünmemiz gerektiğini gerçekten çok güçlü hissediyorum. Artık onlara ihtiyacımız kalmazsa veya platform yetişirse, onları çıkarmak için büyük bir yeniden yazma gerekmez.

Chris: Yani artık kullanmadığımız bir sürü stilimiz var, bu yüzden kişisel olarak CSS'nizi işlenmiş işaretlemeye karşı denetleyen ve ihtiyacınız olmayan şeyleri çeken bir derleme aracı teknolojisini tercih ederim. Çünkü yolun aşağısında bir platform yetişirse, her şeyi değiştirmek zorunda kalmadan yapım aracının o parçasını çekebilirsiniz. Sadece sahip olduklarınızı genişletiyor, oysa CSS ve JS size aynı türden bir fayda sağlamıyor. Ben sadece bunu seçiyorum, ancak bu teknolojilerin çoğunu daha geniş olarak düşünüyorum.

Chris: React veya Vue gibi şeylerin muhtemelen tarayıcıların sonunda yetişeceği bazı inek yollarını açtığını ve muhtemelen aynı olmasa da benzer yaklaşımları kullandığını hissediyorum, bu yüzden orada daha az yeniden yazma olabilir. Etrafına takılan birçok ekosistem olayı daha az olabilir.

Drew: Web platformunun yavaş ve dikkatli hareket etmesi doğru değil mi? Beş yıl önce, sayfalarımıza JavaScript Döngüleri koyduğumuzu düşünüyorsunuz. Her yerdeydiler. Herkes JavaScript Carousels'i uyguluyordu. Web platformu atlayıp bu ihtiyacı karşılamak için bir Carousel çözümünü uygulasaydı, kimse kullanmıyorken orada oturmayacaktı çünkü insanlar artık Carousels ile yapmıyorlar. Çünkü bu sadece bir modaydı, bir tasarım trendiydi. Buna karşı koymak ve platformun kendisinin şişmesini ve çözülmesi gereken bir sorun haline gelmesini durdurmak için çok daha istikrarlı bir hızda hareket etmesi gerekiyor. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

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

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

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

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

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

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

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

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

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

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

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

Chris: Yep.

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

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

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

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

Chris: Yes.

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

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

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

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

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

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

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

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

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

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

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

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

Chris: İstediğim kadar girmediğimiz diğer şeylerden biri, ama bence gerçekten önemli olan, platformun son birkaç yılda gerçekten büyük bir şekilde yakalanması. Bunu mümkün olduğunca benimsemek, insanlar için daha hızlı, daha az kırılgan, oluşturması ve bakımı daha kolay olan bir web deneyimiyle sonuçlanacak, çünkü tarayıcının size sunduklarını kullanmak gibi daha az bağımlılık gerektiriyor. -kutu. Eskiden sınıflar gibi şeyleri seçmek için jQuery'ye ihtiyacımız vardı. Artık tarayıcıların bunu yapmanın yerel yolları var. JSX, JavaScript'te HTML'yi daha sorunsuz bir şekilde yazmanıza izin verdiği için JSX'i sever. Ancak, Vanilla JavaScript'te size ek bağımlılık olmadan aynı düzeyde kolaylık sağlayan şablon hazır bilgilerimiz de var. HTML'nin kendisi, eskiden JavaScript gerektiren birçok şeyin yerini alabilir, bu kesinlikle harika.

Chris: Biraz konuştuk… bu bir CSS meselesi, ancak bağlantıların ve bunun nasıl JavaScript gerektirdiğinin üzerinde duruyor. Ancak ayrıntılar ve özet öğeleri gibi şeyleri kullanarak, genişletme ve daraltma veya akordeon öğeleri gibi açıklamaları komut dosyası oluşturmaya gerek kalmadan yerel olarak oluşturabilirsiniz. Sadece bir kullanarak otomatik tamamlama girdileri yapabilirsiniz… Sadece söylememeliyim, o kelimeden nefret ediyorum. Ancak mütevazı bir girdi öğesi ve ardından bazı seçeneklerle onunla ilişkilendirilen bir veri listesi öğesi kullanmak. Vanillajstoolkit.com'da bu şeylerin nasıl çalıştığını merak ediyorsanız, platformun size verdiği bir sürü JavaScript malzemem var. Ama aynı zamanda JavaScript gerektiren bazı şeylerim de var ve şimdi bazı kod örneklerinin bununla birlikte gitmesini istiyorsanız ilginç olabilecek şeyler de yok.

Chris: CSS tarafında, şimdiye kadarki en popüler Vanilla JS eklentim, bağlantı bağlantılarına aşağı kaydırmayı canlandırmanıza izin veren bu kitaplık. Bu çok büyük. Yazmak zorunda kaldığım en zor kod parçası. Ve şimdi tamamen tek bir CSS satırı ile değiştirildi, kaydırma davranışı pürüzsüz. Daha performanslıdır. Yazmak daha kolay. Davranışını değiştirmek daha kolaydır. Bu sadece daha iyi bir genel çözüm.

Chris: Keşke daha fazlasını yapabilseydik dediğim diğer şeylerden biri de çok sayfalı uygulamalara yaslanmak. Burada kendimi biraz haklı hissediyorum, çünkü yakın zamanda Google'da birinden, şimdi de bu yaklaşımı gerçekten zorlayan bir makale gördüm. Bu devasa açısal ve ardından çerçeve göz önüne alındığında, bunun oldukça ilginç olduğunu düşündüm… Google'ın birkaç yıl önce başlattığı her şey, patlama. Bu konuya geri döndüklerini görmek ne güzel. Statik site oluşturucular ve Netlify ve CDN önbelleğe alma gibi harika hizmetler gibi şeyleri kullanarak, tüm farklı görünümleriniz için ayrı HTML dosyaları kullanan kişiler için inanılmaz hızlı web deneyimleri oluşturabilirsiniz. Bu kullanıma hazır şeylerden bazılarına yaslanmak gibi.

Chris: Bunun sizin için gerçekçi olmadığı, daha fazla JavaScript'e ihtiyaç duyduğunuz durumlarda, bir tür kitaplığa ihtiyacınız var, belki de sadece endüstrinin devlerini aramak yerine önce daha küçük ve daha modüler yaklaşımlara bir göz atabilirsiniz. React yerine Preact işe yarar mı? Açısal yerine… Yani Vue yerine Alpine JS çalışır mı? Ayrıca, size çerçeve benzeri bir deneyim sunan ve ardından tüm kodunuzu Vanilla JavaScript'te derleyen, şimdi Svelt olarak adlandırılan gerçekten ilginç bir ön derleyici de var. Böylece, sadece ihtiyacınız olan şeye sahip olan ve başka hiçbir şeye sahip olmayan bu gerçekten küçük demetleri elde edersiniz. CSS ve JavaScript yerine, HTML'nizi CSS'nizle karşılaştıracak bazı üçüncü taraf CSS linterlerini cıvatalayabilir ve yanlışlıkla orada kalanları çıkarabilir misiniz? Bunun yerine, CSS'nizi yazmanın, Nicole Sullivan'ın nesne yönelimli CSS'si gibi farklı bir yolu işe yarar mı? Bunun hakkında gerçekten konuşamadık, ama insanların kontrol etmesi gereken gerçekten harika bir şey.

Chris: Ve sonra belki de buradaki üçüncü ve en önemli parça, daha az spesifik bir yaklaşım olmasına ve daha fazla insanın akılda kalmasını dilediğim bir şey olmasına rağmen, web'in herkes için olduğudur. Bugün kullandığımız araçların çoğu, iyi internet bağlantılarına ve güçlü cihazlara sahip kişiler için çalışıyor. Ancak eski cihazlarda, sivilceli internet bağlantılarına sahip kişiler için çalışmıyorlar. Bu sadece gelişmekte olan bölgelerdeki insanlar değil. Bu aynı zamanda Birleşik Krallık'taki, ABD'nin kesinlikle berbat internet bağlantılarına sahip olduğumuz belirli bölgelerindeki insanlar. Ülkemizin ortası çok yavaş internete sahip. Londra'nın bir kısmında tarihsel nedenlerden dolayı yeni bir geniş bant bağlantısı yapamayacakları yerler olduğunu biliyorum, bu yüzden gerçekten kötü olan bu eski internet bağlantılarıyla baş başa kalıyorsunuz. Dünyanın her yerinde böyle yerler var. Geçen sefer İtalya'daydım, aynı şey. Orada internet korkunçtu. O zamandan beri değişti mi bilmiyorum.

Chris: Bugün inşa ettiğimiz şeyler her zaman herkes için çalışmıyor ve bu çok kötü. Çünkü web'in vizyonu, onunla ilgili sevdiğim şey, kesinlikle herkes için bir platform olmasıdır.

Drew: Dinleyiciler bu yaklaşım hakkında daha fazla bilgi edinmek isterse, kitabınız The Lean Web'de bununla ilgili birçok ayrıntıya girdiniz. Ve bu çevrimiçi olarak mevcuttur. Fiziksel bir kitap mı yoksa dijital bir kitap mı?

Chris: Her ikisinden de biraz. Hayır. Kesinlikle fiziksel bir kitap değil. Leanweb.dev'e gidin. Tamamını internetten ücretsiz okuyabilirsiniz. Ayrıca isterseniz yapabilirsiniz, çok küçük bir paraya EPUB ve PDF sürümleri mevcut, şimdi ne kadar olduğunu unuttum. Bir süredir bakmadım. İsterseniz her şey çevrimiçi ücretsiz. İsterseniz bu konuyla ilgili daha fazla ayrıntıya girdiğim bir konuşmayı da izleyebilirsiniz.

Chris: Ama gomakethings.com/smashingpodcast adresinde Smashing Podcast dinleyicileri için özel bir sayfa da hazırladım çünkü bir şeyleri adlandırma konusunda çok yaratıcıyım. Bu, kitaba ek olarak, bugün bahsettiğimiz şeylerle ilgili bir sürü kaynak içeriyor. Ele aldığımız birçok farklı tekniğe, yazdığım diğer makalelere, bu konuların bazılarına daha derine iniyor ve düşüncelerimi biraz genişletiyor. İnsanlar daha fazlasını öğrenmek istiyorsa, başlamak için muhtemelen en iyi yer orası olacaktır.

Drew: Bu harika. Teşekkür ederim. Yalın Web hakkında her şeyi öğreniyorum. Son zamanlarda ne öğreniyorsun, Chris?

Chris: Evet, birkaç şey. Jeremy'nin progresif web uygulamalarında videosunu izleyerek biraz daha önce buna değinmiştim. Birkaç yıldır kendi ilerici web uygulamamı nasıl yazacağımı öğrenmeyi erteliyorum çünkü üzerinde çalıştığım hiçbir şeye özel bir ihtiyacım yoktu. Geçenlerde Güney Afrika'daki bir öğrencimden, orada olan bazı şeyler yüzünden elektrik kesintileriyle uğraştıklarını öğrendim. Sonuç olarak, birlikte yaptığımız bazı projelerde düzenli olarak çalışamıyor, çünkü elektrikler gidiyor ve öğrenme portalına erişemiyor ve takip edemiyor.

Chris: Benim için şimdi, birinin interneti olmasa bile işe yarayacağı bir deneyim oluşturmak, daha önce olduğundan daha yüksek bir öncelik haline geldi… Belki daha önce olduğunu fark ettim, bu yüzden daha yeni araştırmaya başladım ve bunu bir araya getirmeyi umuyorum. önümüzdeki birkaç hafta. Göreceğiz. Jeremy Keith'in bu konudaki kaynakları yine de mutlak bir cankurtaran oldu. Onların varlığından memnunum.

Chris: Biliyorum, Drew, bu soruyu sormanın nedenlerinden birinin, insanların ne kadar tecrübeli olursa olsun, her zaman öğrendiklerini göstermek olduğunu söyledin. Sadece ilgili küçük bir anekdot. Sanırım yaklaşık sekiz yıldır bir web geliştiricisiyim. Her kullandığımda kelimenin tam anlamıyla italik yapmak için kullanmak için Google CSS özelliğini kullanmak zorundayım. Nedense, doğru olmasa da beynim varsayılan olarak metin dekorasyonuna geçiyor. Farklı şeylerin birkaç kombinasyonunu deneyeceğim ve her seferinde bir kelime yanlışım var. Ayrıca bazen italik yerine italik yazarım. Evet. Eğer bir gün orada birileri, "Ah, bu şeyleri asla öğrenemeyeceğim" gibi hissederse, şunu bilin ki, ne kadar tecrübeli olursanız olun, her zaman Google'da tekrar tekrar aradığınız gerçekten temel bir şey vardır.

Drew: 22, 23 yıldır web geliştiricisiyim ve her seferinde Flexbox'ın farklı özelliklerini Google'a göndermem gerekiyor. 23 yıldır kullanmama rağmen. Ama evet, bazı şeyler sadece… ben yaşlandıkça muhtemelen bunlardan daha fazla olacak.

Chris: Evet. Dürüst olmak gerekirse, daha kolay bir kopyala-yapıştır referansına sahip olmak için Google'da tekrar tekrar yaptığım şeylerden oluşan bir web sitesi oluşturdum çünkü bu Googling'den daha kolaydı.

Drew: Bu kötü bir fikir değil.

Chris: Ben böyle tembelim. Kendimi üç saniyelik Googling'den kurtarmak için koca bir web sitesi yapacağım.

Drew: Dinleyici olarak Chris'ten daha fazlasını duymak istiyorsanız, kitabını web'de yalınweb.dev'de, geliştirici İpuçları bültenini ve daha fazlasını gomakethings.com'da bulabilirsiniz. Chris, Chris Ferdinandi'de Twitter'da. Ve onun podcast'ini vanilyajspodcast.com'da veya genellikle podcast'lerinizi aldığınız her yerde kontrol edebilirsiniz. Bugün bize katıldığın için teşekkürler, Chris. Ayrılık sözleriniz var mı?

Chris: Hayır. Bana sahip olduğun için çok teşekkür ederim, Drew. Kesinlikle harika bir zaman geçirdim. Bu çok eğlenceliydi. Gelip sohbet etme fırsatını gerçekten takdir ediyorum.