Jeremy Wagner ile Çarpıcı Podcast Bölüm 45: Sorumlu JavaScript Nedir?

Bu bölüm, profesyonellerin müşteri siteleri oluşturması, karmaşık projeleri yönetmesi ve çevrimiçi işletmeleri büyütmesi için bir platform olan Wix'teki sevgili dostlarımız tarafından nazikçe desteklendi. Teşekkür ederim!

Bu bölümde Sorumlu JavaScript'ten bahsediyoruz. Kodun sorumlu olması ne anlama gelir ve projelere nasıl farklı yaklaşmalıyız? Öğrenmek için uzman Jeremy Wagner ile konuştum.

Notları göster

• Sorumlu JavaScript web sitesi
• Kitabı A Book Apart'tan satın alın
• Jeremy'nin kişisel web sitesi
• Twitter'da Jeremy

Haftalık güncelleme

• Steven Hoober tarafından yazılan Dokunma Çağında Fitts Yasası
• Web Tasarımı İyi Yapıldı: Frederick O'Brien tarafından yazılan Mükemmel Anlamsız
• Nick Babich & Gleb Kuznetsov tarafından yazılan Sesli Kullanıcı Arayüzleri Oluşturma Hakkında Bilmek İstediğiniz Her Şey
• WordPress'in Leonardo Losoviz tarafından yazılan Blok Protokolüne Katılmasının Etkileri
• Knut Melvar tarafından yazılan Markdown Üzerine Düşünceler

Transcript

Drew McLellan: Teknik yazar, web performansı meraklısı, geliştirici ve konuşmacıdır ve şu anda Google'da çalışmaktadır. A List Apart, CSS-Tricks ve Smashing Magazine için yazmıştır ve yeni bir başlık olan Responsible JavaScript for A Book Apart'ın yazarıdır. Yetenekli bir teknisyen ve iletişimci olduğunu biliyoruz, ancak dünyanın çevresini bir kürek tahtası üzerinde dolaşmak istediğini biliyor muydunuz? Ezici dostlarım, lütfen Jeremy Wagner'e hoş geldiniz. Merhaba Jeremy, nasılsın?

Jeremy Wagner: Eziyorum. Nasılsınız?

Duru: Ben çok iyiyim. Teşekkür ederim. Bugün sizinle bu Sorumlu JavaScript fikri hakkında konuşmak istedim. Bu bir tür yeni yaklaşım veya teknik mi, yoksa tam anlamıyla JavaScript'i sorumlu bir şekilde kullanmaktan mı bahsediyorsunuz?

Jeremy: Kelimenin tam anlamıyla JavaScript'i sorumlu bir şekilde kullanmaktan bahsediyorum. HTTP arşivine göre, mobil cihazlar tarafından indirilen JavaScript miktarında geçen yıl yaklaşık %58'lik bir medyan artışla yaklaşık 290 kilobayttan neredeyse 500 kilobayta ulaştık.

Duru: Vay.

Jeremy: Yani, JavaScript'i sorumlu bir şekilde kullanmaktan bahsettiğimde, kullanıcının ilk olarak şunu söylemesi… inşa ettiğimiz şeyin ne olduğunu ve modern web geliştirme uygulamalarının sunduğu şeyin amacının ne olduğunu eleştirel olarak değerlendirmektir. konuşmak. Ve sanırım bu bir tür… belki geveze değil, ama modern web geliştirmede bir darbe almıyordum, ancak modern web geliştirmenin bir yan ürünü, projelere bağımlılık eklemenin çok kolay olmasıdır. Her şey bir MPM yüklemesi uzağınızda ve her MPM yüklemesinin bir maliyeti vardır, bu maliyet değişir. Ancak bu HTTP arşiv verilerinde, 95. yüzdelik dilimin… yani en yavaş olan veya en yavaş olmayan… veya en fazla JavaScript gönderen deneyimlerin %5'i anlamına geldiğini görüyoruz, bu geçen yıl yaklaşık 875 arttı. kilobayt ila yaklaşık 1.4 megabayt.

Duru: Vay.

Jeremy: Yani muazzam miktarda JavaScript aktarılıyor ve hem yükleme performansı hem de çalışma zamanı performansıyla ilgili sonuçları var.

Drew: Demek oradaki performanstan bahsettin. Modern web deneyimi benim açımdan %10 HTML ve CSS ve %90 JavaScript gibi görünüyor. Ve bunun için bir tür performans değerlendirmesi olmalı. Demek istediğim, aktardığımız veri miktarı hakkında konuştunuz, ancak orada çok fazla JavaScript'e sahip olmanın başka performans değerlendirmeleri var.

Jeremy: Doğru. Yani yavaş bir internet bağlantısına sahip olmak ve biliyorsunuz… Amerika Birleşik Devletleri'nde nerede yaşadığımı, büyük bir şehrin yeterince dışına çıkarsanız, nereye gittiğinize bağlı olarak biraz zorlaşıyor… internetin ne kadar yavaş olabileceği ile başa çıkmak Bu tür kırsal alanlarda ve insanların bu gibi alanlarda yaşaması önemlidir. Bu nedenle, megabaytlarca JavaScript'i göndermeye başladığınızda, yükleme performansı yönü zaten yeterince zorlayıcıdır, ancak iPhone'u olmayan biriyle de uğraşıyor olabilirsiniz… iPhone X veya iPhone 13 gibi.

Jeremy: Sadece özellikli bir telefonda olabilirler ya da sadece bir tür bütçe Android telefon gibi, sadece hayatta gezinmeye çalışıyor olabilirler. Demek istediğim, çevrimiçi bankacılık, işsizlik yardımı veya diğer devlet yardımları gibi şeyleri düşünün, başvurular için bunun gibi portallar. Çevrimiçi öğrenme, aşırı JavaScript'in büyük metropol alanlarında ve hatta geniş bant internet tarafından iyi hizmet verilmeyen metro alanlarında ve daha yavaş cihazlarda yaşamak için yeterince şanslı olmayan insanlar için gerçekten zararlı bir etkiye sahip olabileceği birçok yer var. . Sanırım geliştiriciler olarak şöyle bir bakma eğilimimiz var… MacBook'ları veya bu ileri teknoloji cihazları satın alıyoruz ve bazen JavaScript'i aşırı kullandığımızda bu sorunların nerede ortaya çıkabileceğini gerçekten göremiyoruz.

Drew: Ve orada bahsettiğin gibi, bazen bir hizmete erişemeyerek en çok kaybedecek türden olan kişiler bu tür şeyler yüzünden cezalandırılıyor. Hızlı veri bağlantıları veya çok yetenekli cihazları olmayan kişiler bazen her şey anlamına gelen hizmetlere erişirler… bu onlar için erişebilecekleri her şey anlamına gelir. Bu nedenle, bazı yönlerden neredeyse bir insan hakları sorunu haline geliyor.

Jeremy: Evet. Demek istediğim, web performansının iş değeri açısından çerçevelendiğini görme eğilimindeyiz. Bir e-com'da performans danışmanıydım ve büyük bir gıda şirketi, büyük bir e-com gibi... bir mağaza gibi, bir elektronik mağazası gibi ve bunu yapmak çok cazip, değil mi? Çünkü bir iş için çalışırken, demek istediğim, açıkçası finansalların sağlıklı olmasını istiyorsunuz ve web performansının bunda bir rol oynadığını düşünüyorum. Sanırım bunu kanıtlayan birkaç vaka çalışması var. Ancak, bir de insani yönü var ve hatta manavlar ve bu tür şeyler gibi işletmeler için bile. Evet, gelir odaklılar. Sağlıklı mali kaynaklara sahip olmak istiyorlar ve bu nedenle web performansı bunun bir parçası, ancak aynı zamanda kritik bir ihtiyaca da hizmet ediyorlar, değil mi? Sanki yemek zorundasın, değil mi?

Jeremy: Ve bazı insanlar şu ya da bu nedenle eve bağlı olabilir. Bir arabaya kolayca binemeyebilirler. Arabaları olmayabilir. Dolayısıyla, geçimlerini sağlamak için bu hizmetlere güveniyorlar, ancak bundan daha fazlası, ihtiyaç duyduklarında yardım ve özellikle kriz müdahalesi ve bu tür şeyler gibi. İstismara uğrayan ve evinden atılan bir ortağın akıllı telefonuna dönüp krize müdahale ve yardım için bir portal bulmaya çalışmak için Google'a başvurabileceğini söylemenin çok abartılı olduğunu düşünmüyorum. JavaScript de bu tür hedeflerin önüne geçebilir ve bu insan ihtiyaçlarına hizmet edebilir. Ona biraz fazla yaslanma eğiliminde olduğumuzda.

Drew: Demek istediğim, son 18 ay içinde COVID ve insanların izolasyona girmesi ve sizin dediğiniz gibi, bakkalların teslim edilmesi için sipariş verme ihtiyacı ile buna bir çeşit bakış gördük. Web bu noktada onlar için bir yaşam çizgisi haline gelir. Kendini kötü hissediyorlar, tecrit edildikleri için konaklama yerlerinden çıkamıyorlar ve yiyecek ve temel malzemeleri almaları gerekiyor. Yani evet, hepimiz için günlük hayatın giderek daha önemli bir parçası olduğunu düşünüyorum.

Jeremy: Aynen. Ve bir tür cihaz hikayesine geri dönersek, Tim Kadlec birkaç yıl önce harika bir parça yazdı, sanırım iki yıl önceydi, belki üç yıl önceydi, ama adı Performansın Uzun Kuyruğuna Öncelik Verme olarak adlandırıldı. Ve buna baktığınızda… yani web performansı deyiminde, saha verileriyle laboratuvar verileri hakkında konuşuyoruz. Ve laboratuvar verileri, deniz fenerini çalıştırdığınız veya nasıl çalıştığını görmek için bir web sayfası testine bir web sitesi attığınız zamanki gibidir. Bunların hepsi gerçekten faydalı araçlar, ancak bu saha verilerine baktığınızda, gerçekten daha büyük bir resim ve kitlenizin gerçekte kim olduğuna dair daha büyük bir görünüm elde etmeye başlıyorsunuz. Ve bu yazıda Tim Kadlec, performansın uzun kuyruğuna öncelik vermenin ne anlama geldiğinden bahsediyor. Yani tüm bu cihazlar… bizim geliştiriciler olarak sahip olduğumuz cihazlar kadar etli ve güçlü olmayabilir.

Jeremy: Ve bu makalenin arkasındaki fikir, eğer 90. veya 95. yüzdelik dilime odaklanabilirsek… ve bu deneyimi bu insanlar için iyileştirebilirsek, hızlı cihazlardakiler de dahil olmak üzere herkes için daha hızlı bir web oluşturuyoruz. ABD'de bununla ilgili bir veri noktasına saldırın ve bu da tıpkı statcounter.com gibi. 28 puan gibi bir şey… İnsanların yaklaşık %28'i bu aracın yakaladığı bir iOS cihazında. Ve bunların yaklaşık %21'i Android. Ve Android, bu uzun cihaz kuyruğunun iyi bir bölümünü temsil etme eğilimindedir, çünkü Android yekpare değildir. Birden fazla cihaz üreticisi Android telefonlar üretiyor, ancak dünyayla bir tür tezat oluşturacak şekilde, dünya yalnızca Amerika Birleşik Devletleri'nden daha fazlası olduğu için, iOS kullananların yaklaşık %16'sı ve Android kullananların yaklaşık %41'i. Bu nedenle, bu daha yavaş veya potansiyel olarak daha yavaş deneyimlere öncelik vermek gerçekten işe yarıyor.

Drew: Kitabınızda cihazın termal kısmasıyla ilgili bir şeyler okumuştum, ki bu daha önce gerçekten hiç düşünmediğim bir şeydi. Oradaki endişeler neler?

Jeremy: Buradaki endişeler ve ben hiçbir şekilde mikroişlemciler konusunda uzman değilim. Ben sadece muhtemelen biraz fazla yazan bir web geliştiricisiyim, ama… yani termal kısmanın arkasındaki fikir ve bu sadece telefonlarda ve tabletlerde değil, tüm sistemlerde var, bir mikroişlemcinin… aşırı iş yükü aldığında veya gerçekten sadece genel olarak iş yükleri, bu işin atık ürünü ısıdır. Ve böylece cihazların bunu azaltmanın yolları var. Dizüstü bilgisayarınızın hem pasif hem de aktif bir soğutma cihazı olması gibi.

Jeremy: Yani pasif bir soğutma cihazı, bir soğutucu veya bir tür ısı dağıtıcı gibidir. Ve bunun aktif kısmı, ısıyı daha verimli bir şekilde dağıtmak için bir fan gibidir. Bazıları özel PC yapıları gibi sıvı soğutma kullanabilir, ki bu nispeten daha uç bir örnektir, ancak bir cep telefonunda buna sahip değildir çünkü taşınabilirlik sizin için uygunsa, tüm bunların içinde bir fanı gerçekten nereye sığdıracaksınız? şey, değil mi?

Jeremy: Yani bu cihazların bu ağır iş yükleriyle başa çıkabilmesi için, işlemcinin hızını yapay olarak azaltabilirler, örneğin, o cihaz o saat hızının yükseltilebileceği bir duruma girene kadar saat hızını düşürmek gibi. Ve bunun sonuçları var çünkü tonlarca ve tonlarca ve tonlarca JavaScript'i çiğniyorsanız, kablodan aşağı inen bu büyük parçaları seversiniz, peki bu işlemeyi başlatır, değil mi? Bu nedenle, derlemede ve ardından yürütmede değerlendirme ve ayrıştırma yoluyla çok fazla işlem yapılır. Ve bunu bir veya iki megabayt JavaScript ile yapıyorsanız ve arka planda farklı sekmeler gibi devam eden birçok başka işleminiz varsa, durumunuzu koyabilecek bu tür şeyler… cihaz termal olarak kısılmış bir duruma girebilir, bu da bu fazladan işi daha az üstlenebileceği anlamına gelir.

Drew: Yani bu bir tür olumsuz geri besleme döngüsü. değil mi? Cihaza yapacak çok iş verirsiniz. Çok ısınır ve sonra kısılması gerektiğinden bu işi fiilen yürütme kabiliyeti azalır.

Jeremy: Doğru. Ve yine, ben bir mikroişlemci uzmanı değilim. Eminim, eğer buna gerçekten aşina olan bir mühendis, beni bazı ayrıntılarda düzeltebilirse, ancak genel fikir şu ki, evet, çevresel baskı arttıkça, cihaz daha az yetenekli hale geliyor. bu baskı azalana kadar bu ağır iş yükleriyle başa çıkın.

Drew: Yani en son Apple M1 Max'ten tüm cihaz yelpazesi için JavaScript yazıyoruz yeni işlemci değil mi? Dizüstü bilgisayarlar, bir web sayfası oluşturmak için zar zor yeterli çalışan RAM'e sahip cihazlara kadar. Ancak web böyle başlamadı, daha genç dinleyiciler, eskiden JavaScript olmadan etkileşimli web deneyimleri oluşturduğumuzu bilmek isteyebilirler. Büyük, ağır çerçevemiz yıkımımız olacak.

Jeremy: Çerçevelerin bir zamanı ve yeri olduğunu söyleyebilirim ve bu kitaptan alıntıları okuyanlar benim çerçeve karşıtı olduğum fikrini alabilirler. Ve birkaç çerçeveyi kesinlikle eleştiriyorum, ancak bir amaca hizmet ediyorlar ve bunları iyi bir kullanıcı deneyimini koruyan veya iyi bir kullanıcı deneyimiyle sonuçlanabilecek şekilde kullanmak mümkün. Ancak yeterince yapmadığımızı düşündüğüm şey, bu çerçeveleri nasıl zarar verdikleri açısından eleştirel olarak değerlendirmek… çalışma zamanı performansı, değil mi? Bahsettiğim türden şeyler, bir düğmeye tıklarsanız ve cihazın bu girdiye yanıt vermesi bir belki iki saniye sürer, çünkü arka planda çok fazla şey oluyor. Analitik toplama gibi üçüncü taraf JavaScript öğeleriniz var ve ardından iş parçacıkları üzerinde çalışan diğer şeyler gibi.

Jeremy: Ve eğer bir çerçevenin çalışma zamanı performansını eleştirel olarak değerlendirmezseniz, kullanıcılarınıza daha iyi hizmet vermek için masada bazı fırsatlar bırakıyor olabilirsiniz. Bu yüzden iyi bir örnek, her zaman kullanmayı sevdiğim tepkiye karşı eylem öncesidir. Bir süredir bu davulu çalıyorum. Bir süre önce CSS-Tricks için bir mobil gezinme menüsü gibi temel bir tıklama etkileşiminin profilini çıkaran bir makale yaptım. Kulağa önemsiz geliyor, ancak bulduğunuz şey, tüm cihazlarda tepki vermenin daha iyi çalışma zamanı performansı sağladığı, ancak temelde aynı API'ye sahip olduğu. Farklılıklar var, bazı küçük farklılıklar var ve eylem öncesi uyumla üzerine yazılabilecek şeyler var, ama bu kadar basit… ve basit bir seçim dememeliyim, ama bu seçim, bu temel seçim, bir deneyim arasındaki fark olabilir. tüm kullanıcılar veya en azından çoğu kullanıcı için gerçekten iyi çalışan veya yalnızca bazıları için iyi çalışan bir deneyim. Umarım bu bir anlam ifade etmiştir.]

Drew: Demek istediğim, tüm çerçeveler ve yapı araçlarıyla, ağaç sallamak ve gönderdikleri paketleri ve daha sonra tarayıcıya nasıl iletildiklerini optimize etmek gibi şeyler yapmakta her zaman daha iyi oluyorlar. Büyük çerçeveleri kullanırken, bu kadar büyük bir uygulamayı, kendinize ait çok fazla kodu yazarken, çerçevenin tüm soyutlamaları nedeniyle daha az kod göndermenize olanak tanıdığını düşündüğünüz bir devrilme noktası var mı?

Jeremy: Bu cevaplaması biraz zor bir soru. Bunun bir yönü, çerçevenin kendisinin asla optimize edemeyeceğiniz bir kod miktarını temsil etmesidir. Yani ince bir çerçeveye sahip olmak, ön-eylem gibi veya herhangi bir sayıda benzer… Veya örneğin büyü gibi, bu çok yardımcı olur. Ancak gördüğüm ve HTTP arşivinden elde edilen verilerin bu noktayı desteklediğini düşündüğüm sorun şu ki, mikroişlemciler ve ağlardaki bu gelişmelere sahip olduğumuzda ve daha hızlı hale geldiğinde, bu kazancı tüketme eğiliminde olduğumuz anlaşılıyor, değil mi?

Jeremy: Asla gerçekten ilerlemediğimiz bu koşu bandında olma eğilimindeyiz. Ve bilmiyorum, tarihin ne olduğu konusunda kahin değilim… ya da üzgünüm, çerçevelerin geleceğinin nasıl göründüğü. Eminim toplanabilecek bazı verimlilik kazanımları vardır. Ancak, JavaScript'in ne kadar ham JavaScript olduğu konusunda sahada gördüğümüz şey… sadece ham JavaScript miktarı kullanılıyor. Bana bunun çıkış yolumuzu otomatikleştirebileceğimiz bir sorun olduğunu söylemiyor. Bence biz… insan olmalı ve müdahale etmeli ve kullanıcıların çıkarlarına en uygun kararları almalıyız. Aksi takdirde, bu koşu bandından indiğimizi görmüyorum, belki kariyerimde değil ama bilmiyorum.

Drew: Kitapta web siteleri ve web uygulamaları hakkında konuşuyorsunuz ve farkı anlamanın ve hangisiyle çalıştığınızı nasıl geliştireceğiniz ve optimize edeceğiniz konusunda stratejinizi seçmenize yardımcı oluyor. Bize biraz bundan bahset.

Jeremy: Bu gerçekten iyi bir soru. Ve bunu A List Apart için yazdığım ve bu kitabın bir nevi girişi olan Responsible JavaScript Part One adlı isimsiz başlıklı makalede yazıyorum. Bu terminolojiye çok şey yüklediğimizden mi? Teknik bir yazar olarak, ikisinin birbirinin yerine kullanıldığını görüyorum. Web sitelerinde gördüğüm şey, bunun bir çeşit çok yaşlı bir deneyim olduğu, değil mi? Bu bir belge koleksiyonudur. Şimdi bir belge… bu belgeler, son zamanlarda terimin bir tür olduğu gibi, bu küçük adalar gibi, insanların işlerini halletmelerini sağlayan bu küçük işlevsellik adaları gibi gömülü işlevlere sahip olabilir.

Jeremy: Ama bir de web uygulamaları var ve web uygulamaları yerel uygulama benzeri işlevsellik çağrışımına sahip. Yani tek sayfalı uygulamalardan bahsediyoruz, karmaşık etkileşimi yönlendirmek için yüksek miktarda JavaScript'ten bahsediyoruz. Web uygulaması modelinin mantıklı olduğu zamanlar da vardır. Mesela Spotify buna güzel bir örnek. Bu bir web uygulaması olarak daha iyi çalışır. Bunu kullanmayı denemek veya bunu çok sayfalı bir uygulama olarak tasarlamak istemezsiniz. Geleneksel bir web sitesi gibi, ancak bunun sürdürülebilir bir varsayılan olmadığını düşünüyorum, çünkü her proje için varsayılanınız, “Eh, tek ihtiyacımız olan, istemci tarafı yönlendirici ve ağır bir çerçeve gibi tek bir sayfa uygulamasını göndermemiz ve hepsini boşaltmamız gerektiğidir. sunucudan istemciye bu işleme işleminin. Kullanıcıları istemeden de olsa hariç tuttuğunuz, ancak yine de onları hariç tuttuğunuz bir noktaya gelmeye başladığınız yer burasıdır.

Drew: Sizce bir web sitesi yayınlayacağımız ve bu sitenin herhangi bir etkileşimli işlevselliğe sahip olabileceği yaklaşımını benimseyen insanlarla, “Biz bir yazılım şirketiyiz, biz bir yazılım şirketiyiz. bir ürün, bir yazılım ürünü ve bunu sunacağımız platformumuz, çoklu platformlar için yerel uygulamalardan ziyade web'dir.” Soruna tamamen farklı şekillerde yaklaşmaları muhtemel mi? Bu noktada bakış açınıza bağlı olarak düşünceler farklı mı?

Jeremy: Bu zor bir soru. Böyle-

Drew: Bunu söylemek benim için zordu.

Jeremy: İyi bir örnek olan bir şirketin haber gibi olacağını söyleyebilirim, değil mi? Bir tür web sitesi modeli tarafından iyi hizmet edilirler, çünkü kelimenin tam anlamıyla bir belgeler, makaleler koleksiyonudur. Ve bu deneyimleri geliştiren insanlar muhtemelen Spotify gibi bir şirketten veya Envision gibi büyük bir web uygulamasına sahip bir şirketten veya bu tür bir şeyden farklı bir beceri setine sahip olacaklar. Ve evet, bence buna farklı açılardan gelecekler. Şöyle bir baktım, bir segment var… veya en azından web geliştirme topluluğunu genel olarak böyle algıladım, geleneksel olmayan yazılım geliştirmeden gelen web geliştiricilerinden oluşan bir insan segmenti var. arka planlar, değil mi? Ben de bu insanlardan biriyim, biraz çocukken internetle uğraşıyordum, değil mi?

Jeremy: Ortaokulda olduğu gibi ve o zamanlar gerçekten sevdiğim video oyunları gibi herkes için aptal hayran sayfaları yapmak gibi. Ve hiç bu tür bir bilgisayar bilimi eğitimi almadım. Yol boyunca aldığım bilgisayar bilimi kavramları var. Ayrıca, özellikle son beş ila 10 yılda bu konuya daha bilgisayar bilimi odaklı bir şekilde yaklaşan geliştiriciler de var. Ve bence bu… bu farklılıklar ve deneyimler, bu grupların her birinin web için en iyi nasıl geliştirilebileceği konusunda kendi sonuçlarını çıkarmasına yol açacak. Ama bence gerçekten yapabileceğiniz tek yol… Web için sürdürülebilir bir şekilde geliştirebilmeniz, inşa ettiğiniz şeyi eleştirel olarak değerlendirmek ve bu ürünlerin kullanıcılarına en iyi hizmeti veren bir yaklaşım etrafında uyum sağlamaya çalışmaktır. Ve bu, web sitesi ve web uygulaması modelleri, bu şeyleri değerlendirdiğimde kafamın içinde oturuyor.

Duru: Evet. İlginç. Demek istediğim, kitapta aslında bazı çalışmalarımdan alıntı yapıyorsun. Çok teşekkürler. Ve temel olarak PHP Apache'deki sıkıcı teknoloji seçimim ve elle yuvarlanan JavaScript serpme, herhangi bir özel optimizasyon yapmaya gerek kalmadan varsayılan olarak çok hızlı bir kullanıcı deneyimi yaratabilir. Bunun, siteye gelen ve sitedeki içeriği görüntüleyen ön uç ziyaretçiler için harika bir kullanıcı deneyimi sağladığını düşünüyorum.

Drew: Ama aslında, giriş yaptığınızda ve sitede yayınladığınız şeyleri bir kez ters taraftan içerik yazmak için böyle bir ortam gibi hissediyorum. JavaScript ağırlıklı web uygulaması yaklaşımından ziyade bir web sitesi yaklaşımıyla oluşturulmaktan biraz zarar gördüğünü düşünüyorum, öyle ki düşünüyorum… veya belki de her ikisi de olması gerekiyor. Ön ucu güzel statik HTML ve CSS ve küçük JavaScript parçalarıyla yayınlamaya devam etmem gerekiyor. Ancak içerik yazarlığı deneyimi sunmak istediğim arka uç, belki farklı bir teknoloji seçimi daha iyi olurdu. Oldukça ilginç çünkü her zaman bir şey olmak zorunda değil, değil mi? İkili bir seçim değil. Daha çok bir spektrum, sence?

Jeremy: Evet kesinlikle. Ve sanırım toplulukta web geliştirmenin böyle bir spektrum olduğu konusunda daha fazla tartışma görmeye başlıyoruz. Kitabımla ilgilenebilecek insanlar için dürüst olmak gerekirse, kesinlikle yelpazenin web sitesi tarafından geliyor. Ve yine, çünkü bunun her zaman iyi bir varsayılan gibi olduğunu hissediyorum. Bir şeyi nasıl inşa etmek istediğinizi bilmiyorsanız, muhtemelen en iyisi onu JavaScript kullanımını en aza indirecek ve istemciye daha fazla iş yüklemeyi en aza indirecek şekilde oluşturmaya çalışmaktır. Bununla birlikte, fark edilenin mükemmel bir deneyim olduğunu düşünüyorum. Bu iyi yıpranmış ve bir nevi gerçekten "sıkıcı" teknolojilerin eldeki görev için gerçekten iyi çalıştığını düşünüyorum. Ve bunu geliştirici için açık ve etkinleştirici bir şekilde yapar, değil mi?

Jeremy: Bu tür şeyleri gerçekten başarmak için eyalet yönetim mağazaları veya eyalet yönetim çerçeveleri hakkında derin bilgiye sahip olmanıza gerek yok. Ve bence bu, bu özel yaklaşım tarafından iyi bir şekilde sunuluyor. Ancak sizin açınızdan, herhangi bir web sitesinde, istemcideki her şeyi ve bu tür şeyleri yöneten ağır çerçeveler gibi tüm istemci tarafı yönlendirmesine girmeden spektrumun ortasına yaklaşma fırsatları olduğunu düşünüyorum. Sanırım adanın yaklaşımı bunun neye benzediğini keşfetmeye başlıyor. Ve itiraf edeyim, muhtemelen istemeden ada tipi şeyler yaptım. Sanırım uzun bir süredir var, sadece gerçekten bir isim koyamadık. Ancak şimdi, bunu bir orta nokta gibi tanımladığımıza göre, iyi bir kullanıcı deneyimi sunan, ancak yine de daha etkileşimli olan web deneyimlerini görmeye başlayabiliriz. Umarım bu çok dolambaçlı değildi.

Drew: Bir çeşit Flash adasını gömdüğümüz günlere ya da-

Jeremy: Evet.

Drew: Bir sayfada, bunun bizim küçük etkileşimli bölümümüz olduğu bir şey ve geri kalanı bir şekilde etrafta dolaşıyor.

Jeremy: Evet Flash gibi, aman Tanrım, kolejden sonraki kişisel portföyümün üç yinelemesi, gelişmiş Flash taklitleri ve fareyle üzerine gelme efektleri için gerçekten berbattı. Ve bu şeyler gerçekten çok eğlenceliydi. Ve bazen, artık Flash kullanmadığımız için kaybolacak bir sürü içerik varmış gibi özlüyorum. Ve bu gerçekten berbat, ama bir bakıma bahsettiğimiz bu tür adaların habercisiydi. Bu, statik bir web sayfasına ve her şeye sahip olabilirsiniz, ancak o zaman bu gerçekten zengin etkileşimli deneyime sahip olursunuz, tıpkı tam ortasına yerleştirilmiş gibi.

Drew: Uzun süredir aşamalı geliştirme, web deneyimleri oluşturmanın en iyi uygulama yolu olarak görülüyordu. Sizce hala öyle mi?

Jeremy: Muhtemelen olduğunu kabul ediyorum… Muhtemelen değil, aşamalı geliştirme yapmak için daha fazla iş olduğunu kabul etmiyorum çünkü bir bakıma geliştirme deneyiminizi ikiye bölüyorsunuz. Bir web sitesinin minimum uygulanabilir işlevselliğini, sunucunun bu tür önemli etkileşimleri işleyebileceği şekilde sunmaya çalışıyorsunuz. Ama bunun üzerine, "Tamam, peki şimdi bu etkileşimin JavaScript ile biraz daha pürüzsüz olmasını sağlamak istiyorum" diyorsunuz. Hala web siteniz, uygulamanız veya ürününüz ile hedeflerinize ulaşmanın uygun bir yolu olduğunu düşünüyorum.

Jeremy: Ama söylemek istediğim şu ki, bir web sitesindeki her bir etkileşimin bu eşzamanlı gezinme kalıbıyla kolaylaştırılmasını asla tavsiye etmem. Bu nedenle, iyi bir örnek gibi, econ web siteniz için ödeme sayfanız kesinlikle bir sunucu rotasına sahip olmalıdır. Sepete bir şeyler eklemek için bir sunucu rotanız olmalı ve ardından işler biraz daha hızlı ve daha asenkronize olabilmesi için bunu biraz daha keyifli hale getirmek için yeterli JavaScript'i serpebilmelisiniz.

Drew: Performansı ölçmek söz konusu olduğunda. Temel web hayati bilgileri hakkında, çoğunlukla Google'dan çok şey duyuyoruz. Bunlar gerçekten ölçmemiz gereken kriterler mi? Yoksa Google'ın düşünmemizi istediği şey bu mu? Bunun, Google'da çalışmaya başladığınız için zor bir soru olabileceğini anlıyorum.

Jeremy: Evet, evet. Biliyor musun, burada kendim için konuşuyorum. Bence web hayati bilgileri… ilk temel web hayati bilgileri, kullanıcı deneyiminin hangi bölümlerinin önemli olduğunu tanımlamaya yönelik iyi bir girişimdir. Kümülatif düzen kayması ve en büyük İçerikli boya gibi metriklerin, deneyim hakkında gerçekten nicelleştirmeye başlamadığımız şekillerde düşünmeye başladığını düşünüyorum. Özellikle kümülatif düzen değişikliğinden önce, çünkü dokunmayı öfkelendirdiğiniz bir an olduysa, bunun nedeni bir düğmenin sayfada gezinmeyi sevmesidir. Demek istediğim, bunun ölçmek için yararlı bir şey olduğunu düşünüyorum. Kusurlu. Ve bence temel web hayati değerleri üzerinde çalışan herkes, bu metriklerin bazılarında iyileştirmenin istendiği konusunda hemfikir olacaktır. Tamamen aynı fikirde olmadığım başka metrikler de var. İlk giriş gecikmesi gibi, pin koymak biraz zor olan bir metriktir.

Jeremy: Bence gerçekten faydalı, değil mi? Çünkü kelimenin tam anlamıyla söylediğiniz şey, kullanıcının yaptığı ilk etkileşimdeki gecikmeyi ve etkileşimi ölçmek istiyoruz, ancak bu biraz bağlam içermiyor, değil mi? Çünkü bazıları… pek çok şey onu etkileyebilir çünkü her zaman JavaScript ile bağlantılı olmayabilir. İlk giriş gecikmesi, form alanına odaklanmanın neden olduğu gecikmeyi temsil edebilir, değil mi? Bu tür şeyler, HTML'deki şeyler. Bence bu metrikler… ilk giriş gecikmesi gibi metrikler… uzun görev API'sinden girişler, öğe zamanlaması ve bu tür şeyler gibi şeylerle onları bağlamsallaştırabilirseniz faydalı olabilirler. Sonuç olarak, temel web vitals'ın geleceğinin, iyi bir kullanıcı deneyimi sağlayan şeyin ne olduğunu ölçmede yararlı ve araçsal olacağını kanıtlayacağını düşünüyorum. Bu benim kişisel görüşüm.

Drew: Sanırım bu, her zaman kendinize karşı ölçebileceğiniz, kendi gelişmelerinizi ölçebileceğiniz veya puanınız değişirse deneyiminizin daha da kötüleşip kötüleşmeyeceğini ölçebileceğiniz şeylerden biri, trafik ışıklarını çok fazla önemsemek değil, bildiklerinizi önemsemek. sitenizin bağlamı ve bir değişikliğin nasıl bir gelişme sağladığı hakkında.

Jeremy: Kümülatif yerleşim değişikliği gibi metriklerin mükemmel olduğunu düşünüyorum, ancak biraz iyileştirmeden onlar da yararlanabilir. Halihazırda kümülatif düzen kayması, çoğunlukla yükleme sırasında meydana gelen düzen kaymalarını ölçer. Ve bildiğimiz gibi, bir kullanıcı bir sayfayı ziyaret ettiğinde ve bir sayfaya geldiğinde, düzen değişiklikleri her an gerçekleşebilir, değil mi? Dolayısıyla, kesinlikle bu tür bir fenomeni nasıl gözlemlediğimizi geliştirmek için yapılabileceğini düşündüğüm çalışmalar var.

Drew: Bence düzen kararlılığı, aşamalı geliştirme ile çalışırken elde edilmesi biraz daha zor olan şeylerden biri. Bazen, sunucu tarafından oluşturulmuş bir sayfa yüklediğinizde ve ardından bunu istemcide geliştirmeye başladığınızda, bu tür bir düzen kayması yaratma tehlikesi olabilir, değil mi?

Jeremy: Kesinlikle. Ve bu, bileşenlerin hidrasyonunun biraz zor hale geldiği yerdir, çünkü bu bileşenin boyutları herhangi bir nedenden dolayı değişebilir. İstemci tarafı bileşeninde, istemcide yürütülene kadar değerlendirilmeyen durum nedeniyle sunucuda oluşturulmayan içerik olabilir. Bu son derece zor bir problem. Burada oturup gümüş kurşunu sevmiş gibi yapmayacağım.

Drew: Her ikisi de deneyimin başlangıcında büyük bir JavaScript paketini indirme ve çalıştırma sorunu için farklı teknikler olan içe aktarma ve kod bölme dinamiği hakkında biraz konuşmak istedim. Özellikle en basit küçük projelerde, çok sayıda küçük istekte bulunarak aşırı optimizasyon riski var mı, yoksa bu sorunları yaşamayacağınızı en başından önleyerek uygulamada kesinlikle zarar vermeyecekleri bir şey mi? Yoksa bu tür şeyleri düşünmeden önce performans sorunlarını gerçekten görene kadar beklemeniz mi gerekiyor?

Jeremy: Bu yüzden az önce söylediklerinin sonunun buna öncülük etmenin iyi bir yolu olduğunu tavsiye ederim. Tabii ki bu optimizasyonlar çok hızlı ve kolay bir şekilde elde edilemedikçe zamanından önce optimize etmeye çalışmamalıyız, ancak erken optimize etmek çok çaba gerektiriyorsa, gerçekten çok fazla performans sorunu olmadığında, şunu savunuyorum: kod bölme muhtemelen olması gerekmeyen bir şeydir. Muhtemelen bu işlevi önden yükleyebilirsiniz.

Jeremy: Ama örneğin, kitapta bundan bahsediyorum. Büyük bir JavaScript parçası tarafından yönlendirilen yüksek değerli bir etkileşiminiz varsa ve bana göre, büyük bir JavaScript parçası 20 kilobayt anlamına gelebilir çünkü kablo üzerinden sıkıştırılır ve bu, 60 kilobaytlık bir JavaScript yığını olabilir. O zaman bunu ana pakette veya sayısız paketinizden herhangi birinde çıkarabilirseniz, siteniz gönderiliyor olabilir, başlangıç ​​performansına yardımcı olacaksınız.

Jeremy: Ama kitapta, kullanıcının ne zaman yüksek değerli bir etkileşim yapabileceğini algılamak veya en azından ne zaman algılamaya çalışmakla ilgili bir tekniği tartışıyorum. Bu yüzden kullandığım örnek bir JavaScript yığını. Bu, bir formun içeriğini doğrulamak için kullanılır, çünkü HTML form doğrulaması harikadır, ancak aynı zamanda biçimlendirilemez ve oldukça basittir. Yazı eşittir e-posta gibi şeyler için tonlarca esneklik yok, değil mi? Belli bir şekilde değerlendirir. Bununla birlikte, formun istemcide doğrulanması gerçekten yararlıdır çünkü biz de onu biçimlendirebiliriz. Ve bu doğrulamanın görünümünü, marka estetiğinin veya web sitesinin estetiğinin ne olduğuna daha yakın olacak şekilde ayarlayabiliriz. Ve bu örnekte, yaptığım şey şuydu, eğer bir kullanıcı odaklanırsa… hatta formdaki herhangi bir alana odaklanırsa, bu JavaScript parçasını önceden yüklediğimiz nokta budur.

Jeremy: Umarım o zamana kadar olur ve umarım bir formu doldurmak biraz zaman alır, ağın bunu aşağı çekmek için yeterli zamanı vardır, böylece dinamik içe aktarma çağrıldığında, sadece parayı vurabilir. önceden yüklenmiş olanı alın. Bu, orada burada biraz üzerinde çalıştığım bir şey ve her durumda yapmak zor. Örneğin, fareyle üzerine gelindiğinde bunu her zaman güvenilir bir şekilde yapamazsınız çünkü bazı cihazlarda iyi bir işaretçi yoktur. Onlar… onlar… bu musluk girişleri, değil mi? Bu nedenle, örneğin iyi bir işaretçiye sahip olduğunuzdan farklı bir zamanda bir fareyle üzerine gelme meydana gelir.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Çıktığından beri devam eden bir şey, CSS boya API'sini karıştırmak. Paint API'yi gerçekten seviyorum. Yani, her zaman kendi içinde var olmuş bir tür…. kendi yolunda olduğu gibi, çünkü tuval gibi 2B bağlam bir şey olmuştur. Çünkü bu… farkında olmayanlar için, CSS ağrı API'sı, 2B tuval bağlamını gömebileceğiniz ve onu parametreleştirebileceğiniz ve CSS ile kontrol edebileceğiniz bir yoldur; daha önce canlandıramazdınız ve bu tür şeyler.

Jeremy: Ve son zamanlarda bir blog yenilemesi yapıyorum. Yani… Ben büyük bir Final Fantasy geek'iyim, Final Fantasy II gibi az önce yeniden oynadım ve bu yüzden 15 tane var ve 16 tanesi bir ara çıkıyor, ama bu bir tür retro alan. Bu yüzden, farklı karolar kullanarak rastgele bir dünya oluşturmak için CSS boya API'sini kullanıyorum. Yani nehirler ve içinden geçmek gibi şeyler, çimler, ağaçlar ve bu tür şeyler var. Ve bunu parametreleştirerek, kullanıcı web sitemi karanlık modda ziyaret ederse... o boya işi sanki gece olmuş gibi işlenecek. Üzerinde bir çeşit kaplama ve bu tür şeyler olacak.

Jeremy: Ama boyama API'si harika. Tim Holman'a sesleniyorum. Onu JSConf Australia'da gördüm ve üretken sanat eserleri hakkında bir konuşma yaptı. Bu gerçekten sadece, gerçekten ilgimi çekti. Ve sonra Sam Richard, önceki gün CSSConf'ta CSS boyama API'sinden bahsettiğinde, bu iki şey benim için bir araya geldiğinde, "Vay canına, bu çok havalı" gibiydi. Ve aslında Paintlets adında bir şey yaptım! Bu bir Paintlets.Herokuapp.com'dur ve Chrome'u ziyaret ederseniz ve ne yazık ki yapmak zorunda kalırsanız, çünkü henüz çok iyi desteklenmemektedir. Rastgele oluşturulmuş bir grup farklı, rastgele sanat eseri gibi görebilirsiniz ve.. evet, ben sadece… işte buna dahil oldum, üzgünüm. Bununla ilgili uzun hikaye.

Drew: İnanılmaz. Kulağa harika geliyor.

Jeremy: Evet. Evet.

Drew: Sevgili dinleyici, Jeremy'den daha fazlasını duymak istiyorsanız, onu @malchata olduğu Twitter'da bulabilir ve yazı sunumlarını, videolarını ve projelerini kişisel web sitesi jeremy.codes'da bulabilirsiniz, Sorumlu JavaScript şimdi A'dan edinilebilir Ayrı Kitap. Bununla ilgili daha fazla bilgiyi sorumlujs.dev adresinde bulabilirsiniz. Bugün bana katıldığın için teşekkürler Jeremy, ayrılık sözlerin var mı?

Jeremy: İlerleyin ve web için yapabileceğiniz en iyi yolu oluşturun ve kullanıcıyı akılda tutmaya çalışın. Bu benim mantram gibi bir şey ve umarım bu kitap bunu bir nebze olsun sağlamlaştırır.