Smashing Podcast 32. Bölüm: 2020 Yılı İncelemesi

Bu bölümde 2020'ye bir göz atıyoruz. Bu yılki bölümlerimizde kimlerle konuştuk ve ne öğrendik? Öğrenmek için bazı klipleri tekrar dinleyelim.

Notları göster

Her röportajın tam metni de dahil olmak üzere tüm geçmiş bölümlerimizi podcast.smashingmagazine.com adresinde bulabilirsiniz.

2021'de görüşürüz millet!

Transcript

Drew McLellan: Ocak ayında Amy Hupe ile Birleşik Krallık hükümetinin tasarım sistemi üzerindeki çalışmaları ve özellikle ekibin katkıları teşvik ederek sistemin daha geniş organizasyon tarafından benimsenmesini nasıl artırdığı hakkında konuştum. İşte Amy.

Amy Hupe: Çok erken başladık. Dolayısıyla, bir tür kamusal tasarım sistemimiz olmadan çok önce, katkıda bulunanların ilgisini çekeceğini düşündüğümüz insanlarla ilişki kurmaya başladık. Takımda harika bir servis tasarımcımız olduğunu burada belirtmeliyim. Aramıza katıldı… Şu anda tarihleri ​​hiçbir şekilde doğru yazmayacağım ama sanırım 2018'in tamamında bizimle çalıştı ve adı Ignacia. Etrafta dolaşmak ve insanların ilgisini çekmek konusunda harika bir iş çıkardı. Bu yüzden yaptığı şeylerden biri, hükümetteki tüm farklı kalıpları ve bu kalıpların tüm farklı çeşitlerini belirlemekti. Bu yüzden dışarı çıkıp, "Tamam. Devlette adres sormanın 10 farklı yolu vardır. Gelin hep birlikte bunlara bakalım ve hangisinin en uygun yaklaşım olduğuna karar verelim. Bunları nasıl birleştirebiliriz?”

Amy Hupe: İnsanların bunlara bakmalarını ve bir takım olarak bu tür bir konsolidasyon yapmalarını sağlamak için büyük bir atölye çalışması yürüttü. Bence kesinlikle, biz halka herhangi bir şey yayınlamadan çok önce bir tür işbirliği inşa etme yaklaşımı buna gerçekten yardımcı oldu çünkü bu, insanların zaten bu tür bir farkındalığa sahip olduğu ve birçok insanın zaten bir şekilde katkıda bulunduğu anlamına geliyordu. bir başkası biz onu halka açmadan önce. Yani birkaç adım ötedeydik. Bu yüzden bence bu gerçekten önemliydi ve sadece sebattı, insanların katkıda bulunmasına yardımcı olmak için tüm ekibin çok fazla ısrarı.

Amy Hupe: İnsanların bir tasarım sistemine katkıda bulunmalarını sağlarsanız, bu oldukça tatlı bir iş, çünkü insanlara tüm işi sizin için yaptırabilirsiniz ve orada öylece oturursunuz. küçük kod düzeltmelerinizi yapın ve aslında herkes size tüm iyi şeyleri veriyor. Ama aslında, bir tasarım sistemi üzerinde çalışmış olan herkesin bileceği gibi, bu inanılmaz derecede karmaşıktır. Birden fazla farklı ekip için çalışan merkezi bir çözüm yapmak çok zordur.

Amy Hupe: Gerçekten, bir tasarım sistemi üzerinde çalışmadıysanız, birinin bunun ne anlama geldiğini gerçekten anlamasını beklemek mantıklı değil. Yani bir sürü el tutma türü var. Katkıda bulunanların katkıda bulunmalarını desteklemek için yapılacak çok iş var. Bunu daha önce söylediğimi düşünüyorum, ancak birinin bir tasarım sistemine katkıda bulunmasına yardımcı olmak, şeyi kendiniz ve merkezi ekip yapmaktan daha uzun sürer. Ama bence bunun getirdiği değeri kabul etmek ve insanları katkı konusunda bilinçlendirmek, bunu yapmalarına yardımcı olmak, bunu yapmak için bir nevi motive olmalarına yardımcı olmak için çabalarınızda ısrarcı olmak, bence evet, bu sebat gerçekten çok önemliydi. Bu alandaki başarımız.

Drew: Microsoft'tan Stephanie Stimac ve Aaron Gustafson, Edge'in oluşturma motoru olarak Chromium'u benimsemesi hakkında konuşmak için bize katıldı. Aaron'a tarayıcılar arasındaki rekabet ortamını ve aynı işleme motorunda bir araya gelen birden çok tarayıcının bu sağlıklı rekabeti ortadan kaldıracağını ve dolayısıyla açık web için kötü olacağını sordum.

Aaron Gustafson: Bu, kesinlikle uzun zamandır web standartları konusunda biraz zorlandığım bir konu. Bunun için iş gerekçesini tamamen anlıyorum. Microsoft'un bakış açısından, çok anlamlıydı. Ön uç geliştirici perspektifinden, bir sürü farklı motora hitap etmek zorunda olmamak güzel. Demek istediğim, genel olarak, uzun süredir web üzerinde çalışan bizler, render açısından kesinlikle çok fazla yakınsama gördük. Netscape'te yedi gün boyunca yaşadığımız kadar çok sorunumuz yok, burada tıpkı bizim gibi… Her farklı tarayıcı için benzersiz stil sayfaları oluşturan şirketler biliyordum, bu savunulamazdı.

Aaron Gustafson: Ama bence şimdi farklı olan şey, orijinal tarayıcı savaşlarında, tüm bu tescilli motorlara sahip olmanız ve herkesin yeni platform özellikleri ve yeni JavaScript özellikleri veya Microsoft söz konusu olduğunda, JScript oluşturmak ve hepsini bir araya nasıl sığdıracağını anlamaya çalışmak için JavaScript'in tersine mühendislik.

Aaron Gustafson: Ama şimdi açık kaynak projelerinde birlikte çalışma yeteneğine sahibiz ve hala diyaloğumuz var ve hala… Bilmiyorum. Dövüş doğru kelime değil, ancak farklı yaklaşımların etkisi hakkında ciddi tartışmalar yapmak ve birbirleriyle aynı fikirde olmamak ve özellikleri gerçekten iyi yapmak için gerçekten çalışmak ve ayrıca bir Chromium bağlamında temel koda rekabet eden yaklaşımlara sahip olmak proje veya WebKit veya bu türden bir şey veya Firefox alanında Missoula.

Aaron Gustafson: Yani evet. Bir yandan, başka bir işleme motorunu kaybettik ve opera Chromium'a gitmeye karar verdiğinde aynı acıyı hissettim. Ancak Microsoft'un içinde olmaktan ve Chromium projesine gerçekten anlamlı bir şekilde katılmaya ne kadar kararlı olduğumuzu ve sadece arkanıza yaslanıp Chromium'dan gelen her şeyi kabul etmeye değil, aslında neler olduğunu incelemeye ne kadar kararlı olduğumuzu görünce biraz cesaretlenmiş hissediyorum. platform ve buna katılmak… Evet.

Aaron Gustafson: Bu yüzden biraz cesaretlendim ve sadece o projeden almak ve o projede payı olan tüm farklı insanlar tarafından aktarılanları kabul etmek için orada olmadığımızı hissediyorum. aslında orada da işbirliği yapıyor olmak.

Drew: Şubat ayında Stephanie Walter ile Bootstrap ve arkadaşlar gibi UI çerçeveleriyle çalışmak ve bunu kullanılabilir bir arabirimin özelleştirilmiş gereksinimleriyle dengelemek hakkında konuştum. Stephanie'ye, kullanıma hazır bir çerçeve kullanırken oldukça kullanışlı bir kullanıcı arayüzü oluşturmanın mümkün olup olmadığını veya her zaman biraz garip bir uzlaşma olup olmayacağını sordum.

Stephanie Walter: Evet. Sanirim oyle. Ama aynı zamanda yapmaya istekli olduğunuz uzlaşma düzeyine de bağlıdır ve bu her iki taraf için de ödün verir. Şu anda, örneğin, bir malzeme kullanıcı arayüzünde gerçekten belirli düğmeleriniz olduğu için birçok düğmeden ödün veriyorum. Düğmedeki dalgalanma efektini gerçekten sevmiyorum. Mobilde harika çalıştığını düşünüyorum çünkü mobilde, kullanıcı düğmeye tıkladığında veya dokunduğunda bir tür büyük geri bildirime ihtiyacınız var. Ama sonra, düğmenin sonuna kadar giden bu tür bir dalgalanma efekti uygularlar. Özellikle çok fazla düğme olduğunda, biraz abartılı. Ama yine de bu dalgalanma efektini koruyacağız çünkü onu kaldırmak çok karmaşık olurdu çünkü bu React çerçevesinde yerleşikti ve bu düğme üzerinde başka bir fareyle üzerine gelme efektine sahip olmak, bu tür gür bir şey olmayacak daha incelikli bir şey burada. Süper karmaşık olurdu. Yani bu yaptığınız tavizler türüdür.

Drew: Etik tasarım, Trina Felber ve Martin Michael Fredrickson ile yaptığım konuşmanın konusuydu. Tasarımda etik bir yaklaşım benimsemenin ve karanlık kalıplardan kaçınmanın, bir işletmenin yalnızca kısa vadeli satış hedeflerinden ziyade sağlığı ve büyümesi hakkında uzun vadeli düşünme durumu olup olmadığını sordum. İşte Martin.

Martin Michael Fredrickson: Bu tamamen doğru. Bence internet üzerinden yaptığınız işe orta büyüklükte bir şehrin ana caddesinde bir mağazanız varmış gibi bakmanız ve itibarınızı sağlam tutmanız gerekiyor. Müşterilerinize iyi davranmazsanız, müşterilerinize uzun vadede iyi davranmazsanız, işiniz biter çünkü insanlar başka bir mağazaya giderler veya internetten satın alırlar. Dolayısıyla, çevrimiçi olarak ne yaparsanız yapın, gerçekten uzun vadeli bir etki olduğunu düşünmek zorundasınız ve ayrıca karmaşık veya manipüle eden şeyler yapmanın gizli bir maliyeti var. Trina'nın dediği gibi dağınıklığı giderirseniz, uzun vadeli bir tasarruf olur ve iş modelinden bahsederken bu asla hesaplanmaz. Her zaman ne kadar para kazanabileceğinizden bahsedersiniz. Bu kadar para kazanmanın maliyetinden asla bahsetmezsiniz.

Drew: Mart ayında Eduardo Boucas ile farklı kaynaklardan içerik toplayan ve statik site oluşturucunuzun kullanımına sunan Sourcebit adlı açık kaynaklı bir araç hakkında konuştum. Eduardo'ya bunun, başsız CMS'ler gibi araçlarla entegrasyonu sağlayarak bir SSG için yetkilendirme konusunda kullanıcı deneyimini iyileştirip iyileştiremeyeceğini sordum.

Eduardo Boucas: Kesinlikle. Evet. Bunun yolu… Aracı kullanmanın geliştiricilere yardımcı olabilecek iki farklı yolu görüyorum. Biri Sourcebit'i dağıtım rutininizin bir parçası yapıyor. Dolayısıyla, örneğin Netlify gibi bir barındırma platformu kullanıyorsanız ve dağıtım komutlarınızı, bilmiyorum, Hugo build, Hugo için build komutu mu, ya da başka bir şey olacak şekilde yapılandırırsanız, bu tür bir komut Hugo için statik dosyaları oluşturur. Ayrıca bu rutinin bir parçası olarak başka bir komutunuz olur. Bu Sourcebit getirme gibi bir şey olurdu. Böylece derleme zamanında Sourcebit diğer tüm verileri çekecek, Hugo'nun ihtiyaç duyduğu tüm dosyaları oluşturacak ve ardından tüm dağıtım zaten bu dosyaları kullanacak ve CMS'den gelen tüm içeriği dağıtacaktır.

Eduardo Boucas: Bu, Sourcebit için olası bir kullanım örneği. Diğeri ise Sourcebit'i yerel geliştirme iş akışında yerel bir geliştirme olarak kullanmaktır. Böylece Sourcebit'i izleme modu dediğimiz bir şeyle çalıştırabilirsiniz. Sourcebit, uzak veri kaynağındaki değişiklikleri aramaya devam ediyor, bu durumda, başsız CMS. Bu nedenle, bir makale yayınladığınızda veya CMS'de bir girişi değiştirdiğinizde, Sourcebit bunu kabul edecek ve tüm dosyaları sizin için yerel olarak yeniden oluşturacaktır.

Eduardo Boucas: Yerel olarak çalışan geliştirici için bunun anlamı, Hugo sitenizin yanındaki CMS pencerenizin yerel olarak çalışmasını sağlayabilmeniz ve ardından gerçek zamanlı olarak meydana gelen değişiklikleri görebilmenizdir. CMS'de bir şeyi değiştiriyorsunuz ve ardından bu değişikliğin yerel siteye yansıdığını ve çok faydalı bulduğumu görebilirsiniz. Yani bunlar Sourcebit'i kullanmanın iki yolu.

Drew: Dönüşüm optimizasyonu günün konusuydu. Kıdemli podcast yayıncısı ve danışmanı Paul Boag ile konuştuğumda. Sitelerin ziyaretçileri müşteriye dönüştürmek için kullandığı bazı tekniklerden bahsettik. Ama Paul'e yaptığınız değişikliklerin etkisini nasıl ölçtüğünüzü sormak istedim. Paul açıkladı.

Paul Boag: Evet. Kesinlikle. Bence bu, birçok kuruluşun oldukça zayıf olduğu bir konu, başarıyı nasıl ölçecekleri konusunda net olmak. Şimdi, evet, dönüşüm oranınız bir metriktir. Kesinlikle takip etmelisiniz. Ancak dönüşümle bile, kaç kişinin satın aldığından biraz daha karmaşık olmanız gerekir. Ortalama sipariş değerine de dikkat etmeniz gerekiyor. Yaşam boyu değere özellikle dikkat etmeniz gerekiyor, değil mi? Öyleyse, bir müşterinin tüm hayatı boyunca ne kadar değerli olduğu, çünkü karanlık desenler ve bunun gibi şeyler kullanıyorsanız, oldukça yüksek müşteri kaybı elde ettiğinizi pekala görebilirsiniz. Ancak gerçekte dönüşüm, ölçtüğünüz metriklerden yalnızca biri olmalıdır.

Paul Boag: Ayrıca, etkileşime dikkat etmeniz gereken şeyler var, insanların içeriğinizle ne kadar meşgul oldukları, çünkü bu, sonunda dönüşüme devam edip etmeyecekleri konusunda büyük bir fark yaratıyor. Yani, videolarınız ne kadar, izliyorlar mı, sitenizde ne kadar zaman harcıyorlar ve bunu yaparken neye baktıklarına bakıyorsunuz? Sosyal medya ve bu tür şeylerle ilgileniyorlar mı? O zaman son yön açıkça kullanılabilirliktir. Birinin web sitesinde belirli bir görevi ne kadar çabuk tamamlayabileceğini ve sistemi kullanmayı ne kadar kolay bulduğunu ve diğer çeşitli kriterleri ölçmeniz gerekir.

Paul Boag: Bu farklı şeyleri ölçmek için kullanabileceğiniz bir sürü mekanizma var. Orada bazı harika araçlar ve ayrıca benimseyebileceğiniz bazı iyi ölçümler var. Örneğin, kullanılabilirlikle birlikte, ölçmek için çok yararlı bir ölçü olabilecek sistem kullanılabilirlik ölçeği denen bir şey var. Ancak aynı şekilde, maze.design gibi sık kullandığım araçlar da var; bu, birinin satın alma işleminin ne kadar sürdüğünü, örneğin ödemeyi tamamlamasını ölçecek. Yani evet. Bu tür geniş bir metrik yelpazesine sahip olduğunuzda, sadece bu çeyrekte kaç satış yaptığımıza odaklanmıyorsunuz? Büyük resme bakmalısın.

Drew: Nisan ayında Better Blocker'dan Laura Kalbag ile çevrimiçi gizlilik hakkında sohbet ettim. Neyin kamuya açık olduğu ve neyin özel olduğu arasındaki sürekli incelen sınırlar ve özel olarak kabul ettiğimiz şeylerin verilerimizi emanet ettiğimiz şirketler tarafından nasıl bu şekilde görülmeyebileceğinden bahsettik. İşte Laura.

Laura Kalbag: Birkaç yıl önce başıma gelen klasik bir örneğim var. Facebook'taydım ve annem yeni ölmüştü ve cenaze müdürleri için reklamlar alıyordum. Bunun gerçekten garip olduğunu düşündüm çünkü ailemden hiçbiri o noktada bir sosyal medya platformunda bir şey söylemedi. Ailemden hiçbiri Facebook'ta bir şey söylemedi çünkü kimsenin Facebook aracılığıyla bir arkadaş veya aile üyesi hakkında böyle bir şey öğrenmek istemediği konusunda anlaşmıştık. O yüzden söylememiştik.

Laura Kalbag: Bu yüzden kardeşlerime sordum, "Ah, Facebook'ta bu garipliğe neden olabilecek herhangi bir şey söylediniz mi?" Çünkü genellikle sadece makyaj, elbiseler, hamilelik testleri ve konuşmayı sevdikleri tüm o eğlenceli şeyler için reklamlar alıyorum. Belli bir yaştaki kadınlar. Bunun yerine, kız kardeşim bana döndü. O, "Pekala, evet. Arkadaşım Avustralya'da yaşıyor.” Bu yüzden ona Facebook Messenger'da bir mesaj gönderdim ve ona annemizin öldüğünü söyledim. Elbette Facebook kardeş olduğumuzu biliyordu. Oraya eklemeyi seçebileceğiniz o ilişki bağlantısına sahiptir. Demek istediğim, birlikte olduğumuz yerlere, aynı soyadını paylaşmamıza ve "Oh, bu onun ayağına basmak için uygun bir reklam" kararına bakılırsa muhtemelen kardeş olduğumuzu tahmin edebilirdi.

Drew: Teknolojinin bu kararları bizim yerimize verdiğini ve bu örnekteki insanları potansiyel olarak oldukça hassas veya savunmasız bir zamanda etkilediğini düşünmek iç karartıcı değil mi?

Laura Kalbag: Evet. Korkunç olduğunu söylüyoruz. Çoğu zaman insanlar, "Ah, sanki telefonumdaki veya dizüstü bilgisayarımdaki mikrofon beni dinliyormuş gibi oluyor çünkü tam da bu ürün hakkında bu konuşmayı yapıyordum ve birdenbire her yerde yayınımda görünüyor" diyor. Bence asıl korkutucu olan, çoğunun mikrofonunuza erişimi olmaması. Ama diğer davranışlarınız, aramanız, birbirinize yakınlığınız ve cihazlarınızdaki konumunuz nedeniyle kiminle konuştuğunuzu bilmesi gerçeğidir. Kendimizi birbirine bağlayamayacağımız tüm bu şeyleri, sadece "Ah, belki de bu ürünle ilgilenirler çünkü muhtemelen düşünüyorlardı, zaten hakkında konuşuyorlardı" demek için birbirine bağlayabilir.

Drew: Koronavirüs pandemisi vurduğunda ve birçok ülke bir tür karantinaya girdiğinde, Rachel Andrew ile Smashing'in bunun yerine çevrimiçi olarak gerçekleşmesi planlanan yüz yüze konferansını nasıl uyarladığı hakkında konuştum. San Francisco'daki Smashing konferansını ertelemek zorunda kaldığımdan, Rachel'a yaklaşan konferansları ve atölyeleri sanal alana taşıma planının ne olduğunu sordum.

Rachel An Drew: Çok, çok hızlı bir şekilde, San Francisco'yu ertelememiz gerektiğini anladığımızda, tabii ki atölyelerimiz var, hem ben hem de Vitaly şut ve yarışma atölyeleri yürütüyor ve San Francisco'da her ikisi de tükendi. atölyelerimiz. Açıkçası, bizim için gelip atölyeler düzenleyen birçok insan var, uzun süredir birlikte çalıştığımız insanlar ve onlar tüm atölyelerini buluyorlardı ve bizler için atölyeler yapanlar için aslında bir gelirimizin önemli bir parçası.

Rachel An Drew: Topluluk önünde konuşma, normalde gidip topluluk önünde konuşma yaparak çok fazla para kazanmıyorsunuz. Konuşma yazmak için gereken süreyi ve benzeri şeyleri düşündüğünüzde, çoğu kişiye çok fazla para ödenmez. Atölyeler, bu şeyleri öğretmede iyi olan insanlar için biraz para kazanmak için oldukça iyi bir yol olma eğilimindedir. Yani insanların gelirini temsil ediyorlar. Yani sadece kendime ihtiyaç duymadım ve Vitaly bu yılın başlarında atölyelerimizi kaybetti. Ayrıca birçok Smashing konuşmacımızın da bu atölyelere bağımlı olduğunu fark ettik.

Rachel An Drew: Biz de "Peki, neden onları internete taşımayalım?" diye düşündük. Çok, çok hızlı bir şekilde, gerçekten de o günlerin içinde, ben ve Vitaly'nin bu güce kafa tutan ilk kişiler olacağımıza karar verdik, ama biz olduğumuza göre, ve bir şekilde nasıl yapacağımızı bulabilirdik. Ayrıca çok farklı atölyelerimiz var. Vitaly çok daha fazla işbirlikçidir. Grup aktiviteleri ve işleri var. Sınıf stili öğretiyorum. Aramızda kalarak, "Eh, bir nevi tüm üsleri kapatıyoruz" diye düşündük. Biz de şöyle düşündük, “Hadi yapalım. Bakalım işe yarayacak mı?" Bu yüzden onların reklamını yapıyoruz. Her birinin ne kadar sürdüğünü çözdük ve sonra oturduk ve “Eh, çevrimiçi bir atölye gerçekten neye benziyor? Bu nedir?"

Drew: Teknik bir bakış açısıyla, hemen düşünen web geliştiricileri olarak düşünüyorum, böyle bir şeyi nasıl sunacağız, yani, baktığınız birçok farklı platform olmalı. Baktığınız farklı şeyler nelerdi ve Smashing sonunda ne ile geldi?

Rachel An Drew: Her türlü şeye baktık ve hala bunu yapma sürecindeyiz. Şu anda Zoom kullanıyoruz. Zoom kullanmamızın nedeni erişilebilirlik. Platformların en erişilebilir olanıydı. Açıkçası, seçtiğimiz platform nedeniyle insanları kesmek istemiyoruz. Bence diğer platformlar daha iyi oluyor ve insanlar… Bence birçok platform onlara gelip "Evet, harika görünüyorsun. Ama erişilebilir olmanıza ihtiyacımız var.” Dolayısıyla yakınlaştırma, şu anda insanların kullanması en kolay olanıdır.” Bu yüzden onları kullanmaya başladık. Sonsuza kadar yapar mıyız bilmiyorum. Ama şu anda kullandığımız şey bu ve bu şeyleri yapmanın bir yolu olarak oldukça işe yaradı.

Drew: Zoom yorgunluğu başlarken ve dünya yeni normal olarak adlandırılan şeye hızla uyum sağlamaya başladığında, Phil Smith ile teknolojinin COVID-19 gibi durumlara yanıt vermemize nasıl yardımcı olabileceği hakkında konuştum. React Native uygulaması CardMedic'i yalnızca 10 günde oluşturma. Phil'e, iş için en iyi teknolojiyi seçme ile aşina olduğu ve hızla çalışabileceği teknolojiler arasında nasıl bir denge kurduğunu sordum.

Phil Smith: Bu iyi bir soru. Sanırım proje bana bahsedildiği anda, tüm bunları nasıl inşa edeceğimi tam olarak bildiğimi düşündüm. Çocuğum olmasaydı ve karanlık bir odada oturduysam, üzerinde sağlam, sağlam, sağlam çalışmış olsaydım, muhtemelen yaklaşık beş gün içinde her şeyi tersine çevirebilirdim çünkü gereksinimler çok fazlaydı. uygulama geliştirme deneyimime uygun. Bir API'yi çağırdığı, sonuçları durumda sakladığı ve sunduğu benzer şeyler yaptım. Şimdi, "Tamam, geri dönüp bunu yeniden düzenlemem gerekiyor" gibi bazı kısımların olduğu bir konumdayım.

Phil Smith: Teneke yazmaktan bahsetmiştim ama aslında uygulamada yazı tipleri oldukça gevşek olabilir ve bunun sıkılaştırılması gerekiyor. Arka uçta, çok fazla test yok ve şimdi arka ucu açmaya başlıyoruz çünkü birçok insan öne çıktı ve “Aslında bu harika bir kaynak. Bunu anadilime çevirmek için gönüllü olarak hizmet etmek istiyorum.” Arka uçlar daha fazla insan tarafından kullanılıyor, bu yüzden sadece "Bir dakika, hiçbir şeyin kırılmadığından emin olmak için burada birkaç teste daha ihtiyacım var çünkü şu anda bunu üretimde kullanan insanlar var" diye düşünüyorum. Sanırım sorunuzu cevapladım. Esasen, karar verme yoktu. Sadece onu olabildiğince çabuk oradan çıkarmam gerekiyordu.

Drew: İş yerleri kapalıyken ve çoğumuz evde çalışmaya adapte olduğumuzdan, Ben Frain ile evdeki çalışma alanınızı rahat ve üretken bir yer olacak şekilde optimize etmenin uzun vadeli fiziksel sağlık sorunlarına yol açmayacağı konusunda konuştum. Evde kurulum için sınırlı bütçeler mevcut olduğundan, Ben'e başlamak için en iyi yerin iyi bir sandalye olup olmadığını sordum.

Ben Frain: Bu benim tavsiyem olurdu. Evet. Demek istediğim, bu konularda otorite olduğumu söyleyemem ama görünüşe göre gün boyunca kendini rahat ettirmek için yapabileceğin en önemli şey bu. Oldukça pahalı bir şeyle başlayabilirsiniz. Ben de aynı hatayı yaptım ve sonunda Amazon'dan 45 kiloluk bir ofis koltuğu aldım ve eksende o şey için doğru kelime ne olursa olsun, öne doğru eğilmediğinin farkında değildim. Bulduğum şey, uyluklarımın alt tarafını, bir nevi dizlerimin arkasını kazıyordu ve "O şeyin içinde 45 dakika oturduktan sonra neden bacaklarım ölüyor?" diye düşünüyordum.

Ben Frain: Bence özellikle düzgün ofis koltukları sağlayan bir şirkette çalışıyorsanız, onları hafife alırsınız ve o belirli markaya ve markaya bakana kadar "Aman Tanrım, bu 700 dolarlık bir sandalye.” O kriketi fark ettiğinizde, insanlar bunu düşünmüş ve sizin için çok şey yapmışlar ve sonra belli ki ev ortamınıza geliyorsunuz ve “Neden bir sandalyeye X yüz dolar harcamayasınız?” Diye düşünüyorsunuz. Ama belki buna değer. Özellikle uzun mesafe için buradaysanız.

Drew: Ve elimizdeki uzun mesafe. Uzun vadede ortalıkta dolaşan başka bir şey de Drupal. Haziran ayında Angie Byron ile Drupal 9'daki değişiklikler hakkında konuştum. İlk çıkışından bu yana 20 yıl geçti, Drupal çok yol kat etti. Angie'ye Drupal 9'a geçerken mevcut bir Drupal sitesini yükseltme sürecinin nasıl olduğunu ve uzun süredir devam eden siteleri olanlar için büyük bir yük olup olmayacağını sordum.

Angie Byron: Bence temelde üç senaryo var. Biri, Drupal 8'i çalıştırıyor olsaydınız ve her yeni küçük Drupal 8 sürümü çıktığında, onu hemen bir sürüme yükselttiniz ve yeni şeylerden yararlanmaya başladınız. Yolunuz temelde hiçbir şey olmayacak. Zaten tüm işi yapıyorsun ve iyisin. Bir süre önce Drupal 8'e geçtiyseniz ve BC değişikliklerine ayak uyduramıyorsanız, sizin için biraz iş var.

Angie Byron: Zaten on yıldan fazla bir süredir yazılımımızın en kolay yükseltmesi bu ve size bu konuda yardımcı olacak bir sürü farklı aracımız var. Katkıda bulunan tüm modülleri ve Drupal 9 durumlarının ne olduğunu gösteren bir pano var. Kodunuzu gözden geçirmek ve kontrol etmek ve sahip olduğunuz kullanımdan kaldırılmış işlevleri işaretlemek için otomatik araçlar var ve otomatik olarak yukarı çıkıp bulmak için araçlar var, “Ah, bu modülünüzün en son sürümü ve Drupal 9 hazır mı? Gidip indirmelisin, ”bu tür şeyler.

Angie Byron: Drupal 8'den 9'a kadar, bu kısmın oldukça iyi kapsandığını söyleyebilirim. Drupal'ın önceki bir sürümünden geliyorsanız, Drupal 7 veya daha aşağısını Drupal 9'a söyleyin, bu biraz daha zor görünmeye başlar. Drupal 8'de yaptığımız değişiklikler arasında, örneğin, tamamen nesne yönelimli PHP'ye geçtik ve diğer yazılım projelerinde bulunan tasarım kalıplarını kullanmaya başladık, bu mimari açıdan gerçekten akıllıca bir şey, ama işe yarıyor. yani eski yaşamınızda bir ton özel kodunuz varsa, yani Drupal 9'da bunun için alternatifler bulmanız gerekecek.

Angie Byron: So Acquia, bu sorunu çözmeyi amaçlayan Acquia Migration Accelerator adlı bir ürün ve geliştirmedir, burada eski Drupal 7 verilerinizi okuyan, sizin için eşdeğer Drupal 8 verilerini oluşturan güzel bir React tanımlı uygulama oluşturuyoruz. tüm modüllerin yanı sıra, bu işlemi mümkün olduğunca denemek ve hızlandırmak için eski Drupal 7 modüllerinizle bu haritaya ihtiyacınız olacak çünkü eski sürümlerde olan herkesin hala başarabileceğinden emin olmak istiyoruz. herkesin aynı versiyonda olduğu ve hepimizin birlikte çalıştığı yeni dünya düzeni.

Angie Byron: Ayrıca, Drupal 7'yi de genişlettik… Drupal'ın açık kaynak topluluğu, gelecek yılın Kasım ayı itibarıyla Drupal 7'de yaşamlarının sonu. Her neyse, şu anda COVID'in bunu etkileyip etkilemediğini tartışmamız gerekiyor. Ancak bir dizi farklı şirket var ve Acquia, Drupal 7 için bunun ötesinde en azından 2024'e kadar genişletilmiş destek sunanlardan biri. Böylece bu, kolay bir yükseltmeye sahip olan kişilerin bunu tamamlamak için bir buçuk yılı, insanların daha az kolay bir yükseltmesi var, bunu tamamlamak için potansiyel olarak üç buçuk yılı ya da gerekirse daha uzun bir süreye sahip olmasını sağlıyor. ve herkesin geçiş yapmasını mümkün kılmak ve ardından süreci hızlandırmak için Acquia Migrate Accelerator gibi araçlar oluşturmak için gerçekten çok çalışıyoruz.

Drew: Learning React, Mina Markham ile bir konuşmanın konusuydu. Mina ve ben ilk kez React öğrenecek bir pozisyondaydık. React gibi çerçevelerin tarayıcıya ne kadar yük getirdiğini düşünerek Mina'ya müşterinin eline bu kadar çok kontrol vermenin bir hata olup olmadığını sordum.

Mina Markham: Bir uyarıyla evet demek istiyorum, yine, deneyimlerim çoğunlukla statik web sitelerini içeriyor. Çok fazla ürün geliştirme yapmıyorum. Belki bu alanda, bu daha mantıklı. Ama benim bakış açıma göre, çoğu zaman bir tereyağı bıçağına ihtiyacımız olduğunda balta kullandığımızı hissediyorum. Neden tüm bunları tarayıcıya koymamız gerektiğini bilmiyorum, bu kadar çok iş ve çok fazla şey yapabilirken müşteriye bu kadar çok baskı uyguluyoruz… Bunu çok daha basit yapabileceğimizi hissediyorum. React'i kullanmak konusunda beni her zaman biraz tereddütlü yapan şeylerden biri, ya da tereddüt ediyorum, ama bu beni içten içe kızdırdığında ve aktif olarak karşı çıktığımda demek istediğim, bir web sitesine gittiğimde ve kelimenin tam anlamıyla hiçbir şey yapmazdı çünkü bir hata oluştu veya bir işlev bozulduğu için gerçekten tüm sayfa bozuldu gibi bir şey vardı.

Mina Markham: Çoğu zaman ya hep ya hiç yaklaşımı olması beni biraz rahatsız etti. Geçmişte AEA'da ve geçmişte başka yerlerde verdiğim konuşmalardan biri, sadece gelişiminizi değil, aynı zamanda daha büyük bir sanat yönetimini ve site tasarımını da içeren aşamalı geliştirmenin nasıl dahil edileceği hakkında konuşmaktı. Aşamalı geliştirme veya herhangi bir zarif bozulma yapmayan web sitelerinin örneklerini özellikle belirteceğim. Ya tarayıcıda JavaScript çalışıyor ya da kesinlikle hiçbir şey almıyorsunuz. 1990'dan bu yana web tasarımının tarihi hakkında gerçekten konuşulan sitelerden biri olan web tasarımının tarihi hakkında bilgi veren basit bir site olurdu. Bir sürü zaman çizelgesi, bir şeylerin animasyonu olan güzel bir web sitesiydi. Ancak sadece bir liste ile statik olarak da oluşturulabilirdi. Hiçbir şey göstermemekle, şu anda modern web geliştirmeye yaklaşma şeklimiz nedeniyle kaybolduğunu düşündüğüm güzelce geliştirilmiş deneyimi göstermek arasında adımlar vardı.

Drew: Andy Bell ile BEM, SMACSS ve OOCSS tarzında bir stil metodolojisi olan CUBE CSS hakkında konuştum. Birçok CSS yaklaşımı, kaskad gibi CSS'nin doğal özelliklerine karşı çalışmaya çalışır. CUBE bu davranışı çok benimser. İşte Andy.

Andy Bell: 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 olalım, nasıl yazılması gerektiği. Adı onu veriyor, Basamaklı Stil Sayfaları. Yani bunu tekrar kucaklıyor çünkü bulduğum şey, mikro optimizasyon seviyesine kadar indiğimdir. Son zamanlarda bir çok kişinin düştüğünü gördüğüm bir yoldan geçtim… Yazıda bundan da bahsetmiştim, görebildiğim yer… 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 o durumda bulundum.

Andy Bell: Bunu düzeltme şeklim, detaya inip mikro optimizasyona çalışmak yerine, aslında bileşenlerinizin ne kadar küçük olduğunun önemi olmadığı için işleri kompozisyon düzeyinde düşünmeye başladım. Bir noktada sayfalar olacaklar. Görüş olacaklar. Bundan kaçınamazsınız. İşte 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. O zaman bunun içinde istediğim bileşenleri oraya yerleştirebilirim.”

Andy Bell: 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: Gatsby, Marcy Sutton'la yaptığım sohbetin konusuydu. Statik site oluşturucuların çoğu ön uç koddan bağımsız olsa da, Gatsby React'i kullanır ve bu nedenle, son web deneyiminizin bir parçası olarak Gatsby kodunu çalıştırırsınız. Marcy'ye bu kodun ne olduğunu ve hangi işlevleri sağladığını sordum.

Marcy Sutton: Evet. Bunun en büyük parçasının istemci tarafı yönlendirme olduğunu söyleyebilirim. Yani Gatsby şu anda kaputun altında kaplayıcı kullanıyor. Bir nevi kendi uygulaması. Ancak bu, statik sitenizi ilk kez yüklediğinizde, orada HTML dosyalarının olduğu parçadır. Bu nedenle, kullanıcı herhangi bir nedenle JavaScript'i kapatırsa, siteniz hala orada olmalı, hala içeriğe sahip olmalıdır. Ancak JavaScript etkinleştirilirse, Gatsby sitenizdeki bağlantıları kullandığınızda, o sayfadan kaynakları önceden getirecek olan bu hidrasyon adımı gerçekleşir. Böylece daha hızlı yüklenecektir. Böylece, Gatsby'nin size sunduğu bu JavaScript katmanıyla tüm bunlar etkinleştirilir.

Marcy Sutton: Bunun ötesinde, sitenizde ne kullandığınıza, JavaScript paketinde ne olacağına bağlı. Ancak erişilebilir arayüzler gibi çok fazla etkileşim kullanan şeyler için burası iyi bir yer. Benim için, JavaScript'in her zaman elimde olması ve işaretlememin sadece iyi bir noktada olması gerçekten hoşuma gidiyor. HTML'nizi, JavaScript'inizi ve CSS'nizi her türlü düzgün bir şekilde birleştirmek isteyip istemediğinizin bir tercih meselesi olduğunu biliyorum ve Gatsby'yi oluştururken varyasyonlar için yer var. Her zaman CSS ve JS gibi bir şey kullanmak zorunda değilsiniz. Ancak bu, web sitenizi yazarken size sunulan dinamik JavaScript katmanının gücünü elde etmekle ilgilidir. Ayrı bir dosyadaki bu eklenti gibi değil.

Drew: Statik bir site oluşturucunun genellikle nasıl çalıştığını düşündüğümde, belki de markdown dosyalarındaki içeriği düşünüyorum ve oluşturucu bu içerik üzerinde çalışır ve onu şablonlarla birleştirir ve onlarca, yüzlerce, binlerce HTML dosyası oluşturur. web sitenizin sayfaları. Bir React sitesi veya uygulaması düşündüğümde, daha çok, arayüzlerin React tarafından anında oluşturulduğu tek sayfalık deneyim hakkında düşünüyorum. Yani Gatsby'nin ikisini de yaptığını mı söylüyorsunuz? Tüm sayfaları oluşturuyor ve ayrıca JavaScript ile geliştiriyor mu?

Marcy Sutton: Öyle, evet. Gatsby, Node.js'yi derleme zamanında kullanacak, React bileşenlerinizi gözden geçirecek ve bunları HTML dosyalarında derleyecek, dürüst olmak gerekirse, Gatsby'ye ilk baktığımda JavaScript'i kapatmazdım ve "Tamam, burada başka sayfalar var mı? Bu nedir?" Gatsby'nin varsayılan olarak bu şekilde çalışmasına çok sevindim. Harika olan React bileşenlerinizden yerleşik dosyalar oluşturacaktır.

Marcy Sutton: JavaScript'te olduğu için daha aşamalı geliştirme yaklaşımlarını araştırdım, örneğin, kullanıcılar için aşamalı olarak geliştirilmiş bir şey çıkarmak istiyorsanız, burada JavaScript kapalıysa, JavaScript'i varsayan tüm bu bozuk kodu istemezsiniz var mı. Yani onunla bazı tuhaflıklar var. Ancak, en azından birinin hala bir şeyler satın alabilmesini istediğiniz temel kullanıcı akışlarınız için bu tür bir şey üzerinde çalışabilirsiniz. Bazı destek eklemeniz gerekebilir ve bu kullanım durumları için. Ancak Gatsby'nin bunu varsayılan olarak yayma şekline hoş bir şekilde şaşırdım.

Marcy Sutton: Yani siteleri bu şekilde inşa etmek için yaptıkları bir seçim ve biz her zaman değerlendiriyoruz, hala en iyi yol bu mu? Kullanıcılarımıza istediklerini vermek için ne yapmalıyız? Bu nedenle, Gatsby'nin bir web sitesi oluşturmada elinden gelenin en iyisini yaptığından emin olmak için dahili olarak bazı keşifler yapıyoruz, bu nedenle paket boyutlarını küçük tutuyor ve söylediklerimiz için ödünleşimler yapmak için ön kodlarla performans kodu olduğundan emin oluyoruz. - alma, bunu yedekleyecek veriye sahip miyiz? Bu, bir geliştirici savunucusu olarak benim çok ilgilendiğim türden bir şey, web sitelerinde paketlediğimiz ve paketlediğimiz şeyin gerçekten gerekli olduğundan ve gerçekten yapabileceği en iyi Gatsby sitesini oluşturacağından emin olmak.

Drew: Temmuz ayında Chris Ferdinandi ile konuşurken, modern en iyi uygulamaların web için kötü olup olmadığını sordum. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. 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. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

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

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Ancak ön işlemci dillerini de seçebilirsiniz. Diyelim ki Sass'tan hoşlanıyorsunuz. CSS'de Sass'ı açarsınız ve Sass yazarsınız. Şey, bir şeyin Sass'ı işlemesi gerekiyor. Bu günlerde, Sass Dart veya başka bir şeyle yazılıyor. Theoretically, you could do that in the client. Ancak ön işleme yapan bu kütüphaneler oldukça büyüktür. Sırf o şeyi çalıştırmak için tüm Sass kitaplığını sana göndermek istediğimi sanmıyorum. I don't want to. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Ama şimdi şu şekilde çalışıyor, bir lambda var mı? Sass'ı işler. Küçücük, küçücük, küçücük bir işi var. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Ölçek konusunda endişelenmenize gerek yok. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Ama Sass için bir tane var. Less için bir tane var. Babbel için bir tane var. TypeScript için bir tane var. Bunun için bir tane var… Bunların hepsi, koştuğumuz bireysel lambdalar. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Ancak son zamanlarda bile bundan çok daha fazlası için kullanıyoruz.

Chris Coyier: Here's an example. CodePen'deki her bir Kalemin bir ekran görüntüsü vardır. Bu biraz havalı, değil mi? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Slack'te paylaşırsanız, küçük bir önizlemesini alırsınız. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Nasılsa animasyonlu değil. Sadece performans böyle kazanır.

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

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Bu boyutlar olarak hizmet edin.” Görüntüyü bu boyutlarda yapmak zorunda değilim. You just put the dimensions in the URL, and it comes back as that size, magically.

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

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

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Bunlar, uygulamanızın her türlü medya aracılığıyla paylaşabileceğiniz giriş noktaları haline gelir.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Ayrıca, çok, çok güzel olan Next.js, bu giriş noktasına bağlı diğer sayfaları otomatik olarak önceden getirir, böylece tek sayfalık bir uygulama gibi hissettirir. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

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

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

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

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

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

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

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

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

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Yani her şeyden önce, tepkiselliği değiştirmek için bir motivasyon vardı. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Ama tamam. Yine de sana öğreteceğiz.

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

Natalia Tepluhina: Yani bu yine büyük bir roldü. Sonuncusu, bileşenler açısından değil, işlev yardımcıları vb. gibi birleştirilebilir mantık parçaları açısından soyut mantığın işlevselliğini kaçırdık, ancak Vue etkinliğini de içerebilmelidirler. Burada güzel bir örnek React Hooks olabilir, değil mi? İşlevselliğin parçalarını soyutlamanıza izin veriyorlar ve bu Vue'da açıkça eksikti. Şu anda kulağa "React'ten özelliği çaldın" gibi geldiğini biliyorum. Aslında değil. Fikirler arası tozlaşmanın ekosistemimizin büyük ve güzel bir parçası olduğuna ve geliştiricilerin favoriler arasında geçiş yapmasına yardımcı olduğuna inanıyorum, değil mi? Bu yüzden Vue 3'ü ana sürüm olarak oluşturmak için bu ana özellikler üzerinde çalışıyorduk.

Drew: Ardından, daha az hatayla daha iyi kod yazmamıza nasıl yardımcı olabileceğini öğrenmek için Stefan Baumgartner ile TypeScript'e daldık. Kuruluşların kod temellerini tamamen JavaScript'e taşıma eğilimini gözlemleyerek Stefan'a TypeScript'in bireylerden çok daha büyük ekiplerin yararlanacağı bir şey olup olmadığını sordum.

Stefan Baumgartner: Yani şu anda aynı geçiş sürecindeyim. Bu yüzden gelecekte çok fazla JavaScript yazacak çok sayıda Java ve C++ geliştiricimiz var. TypeScript, yeni programlama dilinin bu korkutucu alanları için bir tür rehber olabilir. Farklı bir programlama dilinden geliyorsanız JavaScript'in pek çok tuhaflığı, bir sürü geçmişi ve bir sürü önyargısı vardır. Bu nedenle TypeScript bir rehber olabilir çünkü tip sisteminde aşina olduğunuz bazı kavramlar vardır.

Stefan Baumgartner: Ama aynı zamanda, özellikle aynı kod tabanında çalışan çok sayıda insan olduğunda veya birbiriyle çalışması gereken çok sayıda insan olduğunda, bu, projenizde ek bir rehberlik katmanı olabilir. Sonunda kötü sürprizlerle karşılaşma. Yani elbette teknoloji hiçbir iletişim sorununu çözmüyor. TypeScript bunun için tasarlanmamıştır. Ancak daha düşük olabilir veya doğru tartışma için çok daha fazla yer açabilir, o zaman konuşmanız gerekmiyorsa, kodunuzdan benden ne bekliyorsunuz, bunun yerine, kodunuz ne yapmalı veya ne yapmalı? kütüphane yap?

Stefan Baumgartner: Her zaman derim ki, eğer başkaları için kod yazarsanız veya çok sayıda insanla kod yazarsanız ya da sadece kendiniz için kod yazarsanız, ertesi gün tekrar gözden geçirin, TypeScript'i düşünün çünkü size yardımcı olabilir. uzun koşu. Bu sadece önümüzdeki haftanın bir sonraki projesi için bir yatırım değil, daha çok tamam diyenler için, hele de aylarca, iki, yıllarca, uzun soluklu projeleriniz varsa, kesinlikle bunu teklif edin. Bir yıl önce küçük kod parçasını yazarken ne düşündüğünüzü asla bilemeyeceksiniz, ancak türler size ne demek istediğinize dair bir ipucu verebilir.

Drew: Kasım ayında David Darnes ile statik site oluşturucu Eleventy hakkında sohbet ettim. Şablonlama hakkında konuştuk ve ne tür bir şablon kullanmanız gerektiği konusunda kaç tane statik site oluşturucunun oldukça fazla fikir sahibi olduğundan bahsettik. Eleveny'nin de aynı türden güçlü inançlara sahip olup olmadığını merak ettim. İşte Dave.

David Darnes: Hayır, söyleyebileceğiniz kadar fikirsizce yaklaştığını söylemeliyim. Biraz kişisel bir bakış açısı, ancak herhangi bir çerçeve veya fikirsiz olabilecek herhangi bir şey görmekte zorlandım çünkü bir şey yaratmak için, bir şeyi nasıl yapmak istediğinize dair bir fikriniz olmalı. Bir tür oksimoron. Eminim insanlar beni bu konuda düzeltebilir. Ama evet. Kendinizi en rahat hissettiğiniz şablonlama diline geçebilirsiniz. Yani, sadece rahat edebileceğiniz dillerden bahsediyorduk. Eleveny, HTML'nizde hangi şablonlama dillerinin kullandığıyla bir bakıma buna hitap ediyor, hatta isterseniz CSS'nizi bile kontrol edin.

David Darnes: Benim için, doğrudan nunjuck'lara gittim çünkü nunjucks, Eleventy'nin içindeki varsayılan şablonlama dilidir. Bu, nokta HTML uzantısını kullanabileceğim ve onu olduğu gibi bırakabileceğim anlamına geliyor. Şimdi insanların kafasını daha da karıştıracağım ve “Nasıl istersen öyle adlandırabilirsin. Onunla gerçekten eğlenebilirsin.” Ancak gidonları kullanabilirsiniz. Bence normal JavaScript şablonunu kullanabilir ve bu şekilde yineleyebilirsiniz. Gidonlar da oldukça popüler ve Liquid. Hepsini kafamın üstünde düşünemiyorum, ancak hepsini yapılandırmada ayarlarsanız, istediğiniz gibi seçebilirsiniz.

David Darnes: Genel olarak dilleri şablonlamanın gerçekten büyük bir hayranı olduğumu söyleyebilirim. WordPress'in içinde twig kullanabileceğinizi öğrendiğimde çok uzun zaman önce değildi ve bu aklımı başımdan aldı. Ben de "Oh, çok şükür. PHP'nin içinde bir for döngüsüyle uğraşmak zorunda değilim." Yine, biraz daha rahat ve anlaşılır, daha okunaklı bir şey düşünüyorum. Yani evet. Eleventy'nin birçok farklı şablonlama seçeneği vardır ve bu farklı seçeneklerden memnun olan insanlara hitap etmelidir.

Drew: Leslie Cohn-Wein ile Netlify'ın Netlify'ı oluşturmak için kendi platformunu nasıl kullandığı ve Dağıtım Önizleme işlevlerinin ön uç değişiklikleri için nasıl etkili bir hazırlama platformu haline geldiği hakkında konuştum.

Leslie Cohn-Wein: Belki de tüm bu sürecin en sevdiğim kısmı, Netlify aracılığıyla elde ettiğimiz Dağıtım Önizlemelerinin büyüsüdür. Ne olur GitHub'da çalışıyorsun, PR'ni yükseltiyorsun. Böylece PR'nizi GitHub'da açarsınız ve bu otomatik olarak uygulamanın Dağıtım Önizlemenizin bir yapısını oluşturacaktır. Bu nedenle, her şeyin olması gerektiği gibi çalıştığından emin olmak için test etmek için aslında uygulamanın Dağıtım Önizlemelerini kullanıyoruz. Testlerimizi çalıştırıyoruz. Kod incelemesi sırasında manuel olarak doğrulamak için kullandığımız şey budur. Bu nedenle, doğrudan GitHub'dan ayarlanan tüm bu sürekli dağıtımlara sahibiz.

Leslie Cohn-Wein: O zaman kurduğumuz diğer harika şeylerden biri de, aslında uygulamamızın yaşadığı aynı depodan çeken birkaç farklı Netlify sitemizin olması. Yani her iki uygulamamız da var. Uygulama için bir tür UI bileşenlerimiz olan bir Storybook örneğine sahibiz. Yani hem uygulamamızın kendisine sahibiz. Storybook UI bileşenlerine sahibiz ve temelde Storybook UI'mizi gösteren bir Netlify sitemiz var ve ardından bir web paketi paket analizörü çalıştıran üçüncü bir sitemiz de var. Bu, size tüm uygulama paketlerinin bir ağaç haritası görselleştirmesini sağlayan bir tür görsel kullanıcı arayüzüdür ve boyutlarını bir şekilde ölçebiliriz ve bu, uygulamanın her dağıtımı giderken bir tür iki kez kontrol etmemiz için bir hatırlatmadır. dışarı, oradaki paket boyutumuzla garip bir şey yapmadığımızı kontrol edebilir ve emin olabiliriz.

Leslie Cohn-Wein: Yani bu sitelerin üçü de uygulamanın tek bir çekme isteğinde oluşturuluyor. Böylece, kontrol etmemiz için hem uygulama Öykü Kitabının hem de o uygulama profilinin önizlemesi, esasen Dağıtım Önizlemeleriniz için bağlantılar alacaksınız.

Drew: Aralık ayında Chris Murphy ile ürün tasarımı ve iş odaklı tasarlanmanın ne anlama geldiği hakkında konuştum. Bireysel bir kurucunun odak noktası tasarlayıp tasarlamadığını, bunun işe sızıp sızmadığını ve bir ürünün doğal olarak onu yaratan kişinin bir uzantısı olup olmadığını tartıştık.

Chris Murphy: Bence bu gerçekten iyi bir soru Drew ve bence cevabı buna bağlı. Bence o kişiye bağlı ve şirketin ölçeğine bağlı. Hiut Denim'e bir göz atarsanız ve öğretimimde Hiut'u çok kullanırsam, bir şeyi iyi yapan bir şirkete gerçekten iyi bir örnektir ve bu onların bir çeşit strapline kotudur. David'in öncekine bakarsanız... David ve Clare, çünkü onlar bir ortaklık. David Hieatt ve Clare Hieatt'ın önceki şirketine, yani Howies'e bakarsanız, o şirket çok büyümüştü, işin içinde çok fazla insan vardı.

Chris Murphy: Ölçek bir kez içeri girmeye başladığında, müşteri yolculuğunda önemli olan tüm küçük temas noktalarına göz kulak olmak çok zor olmaya başlar. Howies'i terk ettiklerinde gerçekten anlamlı olduğunu düşünüyorum, çünkü Howies'i satın almışlardı… Karmaşık. Git internetten oku. Ama Timberland'dı ve Timberland satın alındı ​​ve tüm bu hikaye burada.

Chris Murphy: Bence şu anda odaklandıkları şeyin kot pantolon olması gerçekten ilginç. Bu kadar. Kot pantolonlarla ilgili inanılmaz güzel bir hikaye anlatıyorlar. Ayrıca her şeyi gerçekten çok iyi paketliyorlar ve kot pantolonlar gerçekten hikayeler için bir araç gibi. Bu, Drew, COVID'in diğer ucundan çıkarken daha önemli hale geleceğini düşündüğüm bir şey, umarım diğer ucundan da çıkarız. Bu kotları yapan herkese uygun bir ücret ödeniyor. Şu anda dünyaya baktığımda yaşadığım sorunlardan biri, herkese düzgün bir maaş ödenmiyor ve bunu birisi olarak biraz endişe verici buluyorum… Bakın 51 yaşındayım. Oğlum 25, 24 yaşında. , 25, bunun gibi bir şey. Bu korkunç. Bütün bunları bilmeliyim. O bir düğün fotoğrafçısı. Yaklaşık bir yıldır düğün fotoğrafçısı. İşleri tamamen çökmüş durumda çünkü hiç kimse şu anda gerçekten evlenmiyor çünkü bu sadece zor. Desteği alacak kadar serbest meslek kitabı olmadığı için maaşı yok.

Chris Murphy: O çatlaklardan düştü ve çatlaklardan düşen birçok insan var. Bunun bir tasarım problemi olduğunu, buna bir tasarım problemi olarak bakmamız gerektiğini savunuyorum. Ancak, daha geniş COVID ve hükümet sorununa ve tüm bunlara fazla politik olmadan bakarsam, dün Guardian'da Matt Hancock'un komşusu hakkında bir makale okudum ve İngiltere'den olmayan dinleyen herkes Matt Hancock hakkında bir makale okudum. Sağlık Sekreteri. Bir iş yürüten komşusu, ona mesaj atıyor ve “Bu COVID şeyi için nasıl ürün tedarik edebilirim?” hakkında tavsiye istiyordu. Gazetelerin dediği gibi, doğru insanları tanıdıkları için iş buluyor gibi görünen hükümet bakanlarının arkadaşlarının dediği gibi, kumarla ilgili bir sürü söylenti var.

Chris Murphy: Bu işin diğer ucuna geleceğimizi hissediyorum ve bunu görüyoruz… Bireyler bunu görüyor ve “Peki, bu para nereye gidiyor ve insanlara düzgün bir şekilde ödeme yapılıyor mu? X mağazasından alınan bu bir kiloluk tişörtün fiyatı nedir?” Herhangi bir markadan bahsetmek istemiyorum. Ama her şeyin bedelinin ödenmesi gerekiyor ve yapılan her şeyin, bunu yapmak için insanlara ödenmesi gerekiyor. İnsanların giderek daha fazla ilgilendiğini düşünüyorum, insanlara adil ödeme yapılıyor mu?

Drew: GraphQL, yılın son, tam bölümümüzün konusuydu ve Eve Porcello ile sohbet ettim ve GraphQL'in geliştirme yığınına nerede uyduğunu sordum.

Eve Porcello: Evet. GraphQL, ön uç ve arka uç arasına sığar. Bu ikisi arasında bir tür ortada yaşamak ve ön uç geliştiricilere ve arka uç geliştiricilere birçok fayda sağlıyor. Bir ön uç geliştiriciyseniz, tüm ön uç veri gereksinimlerinizi tanımlayabilirsiniz. Örneğin, büyük bir React bileşenleri listeniz varsa, bir sorgu yazabilirsiniz ve bu, o sayfa için verileri doldurmak için ihtiyaç duyacağınız tüm alanları tanımlayacaktır.

Eve Porcello: Şimdi, arka uç parçasıyla, gerçekten kendine ait, çünkü birçok farklı kaynaktan birçok veri toplayabiliriz. Dolayısıyla, REST API'lerinde ve veritabanlarında ve tüm bu farklı yerlerde verilerimiz var ve GraphQL, tüm verilerimizin bulunduğu yerin kaosunu gerçekten anlamamız için bize bu güzel küçük düzenleme katmanını sağlıyor. Bu yüzden yığının her yerindeki herkes için gerçekten faydalı.