Bloblar Yerine Bloklar Üzerinde Düşünmenin Etkileri

Gutenberg JavaScript tabanlı bir düzenleyicidir (daha spesifik olarak, React tabanlı bir düzenleyicidir), yakında WordPress için içerik oluşturma deneyimini ve (yaklaşan bir aşamada Gutenberg bir site oluşturucuya dönüştürüldüğünde) oluşturma deneyimini değiştirecektir. WordPress siteleri.

Site kurucusu Gutenberg, bir web sitesinin temellerinin nasıl atılacağı konusunda farklı bir düşünme biçimi talep edecek. Halihazırda “eski” model diyebileceğimiz modelde, WordPress siteleri, şablonlar aracılığıyla yapı verilerek ( header.php , index.php , sidebar.php , footer.php ) ve sayfadaki içeriğin tek bir blobdan alınmasıyla oluşturulur. HTML kodu. Yeni modelde, sayfanın her yerine yerleştirilmiş, her biri kendi mantığını kontrol eden, kendi verilerini yükleyen ve kendi kendini oluşturan (React) bileşenleri vardır.

Yaklaşan değişikliği görsel olarak takdir etmek için WordPress bundan hareket ediyor:

…buna:

HTML kodu bloklarından site oluşturmak için bileşenlere geçişin bir paradigma kaymasından başka bir şey olmadığına inanıyorum. Gutenberg'in etkisi PHP'den JavaScript'e geçişten çok daha fazlasıdır: Geçmişte yapılabilecek ve muhtemelen artık bir anlam ifade etmeyecek şeyler vardır. Aynı şekilde, zengin ve güçlü kullanıcı etkileşimleri gibi yeni bir olasılıklar dünyası açılıyor. Web geliştiricileri sitelerini bir dilde oluşturmaktan başka bir dilde oluşturmaya geçmeyecekler çünkü site artık aynı olmayacak; tamamen farklı bir site kurulacak.

Önerilen okuma : Gutenberg WordPress Editörünün Komple Anatomisi

Gutenberg, birçok nedenden dolayı WordPress topluluğu tarafından henüz tam olarak benimsenmedi. Birincisi, yeni mimari, öğrenmesi ve ustalaşması eski PHP tabanlı olandan çok daha zor olan çok sayıda araç ve teknolojiye (React, NPM, Webpack, Redux vb.) dayanmaktadır. Ve yeni işlevler sunan yeni bir yığın öğrenmeye değer olsa da, her anne ve çocuk sitesi bu yeni, parlak özelliklere ihtiyaç duymaz.

Sonuçta, dünyadaki tüm sitelerin %30'unun WordPress siteleri olması tesadüf değildir: Bunların çoğu, Facebook gibi dinamik sosyal ağlar değil, bloglar gibi gerçekten basit sitelerdir. Bir diğeri için, WordPress kapsayıcılığı, herkesin basit bir web sitesi oluşturabileceği anlamına gelir - tasarımcılar, içerik pazarlamacılar ve blogcular gibi kodlama deneyimi olmayan kişiler bile.

Ancak yeni mimarinin karmaşıklığı birçok insanı dışarıda bırakacak (sitemde küçültülmüş JavaScript kodunda hata ayıklamayı düşünmek bile istemiyorum). Ve bir diğeri, Gutenberg yayına girdiğinde, Facebook destekli React dünyadaki tüm web sitelerinin %30'una bir gecede eklenecek. Pek çok insan, herhangi bir JavaScript kitaplığına bu kadar fazla güç vermekten rahatsız olurken, diğerleri Facebook'a güvenmiyor. Bu endişeyi hafifletmek için Gutenberg, React'i diğer çerçevelerde veya kitaplıklarda kodlamayı da etkinleştirmek için özetler; ancak pratikte React şüphesiz baskın JavaScript kitaplığı olacaktır.

Yine de, yeni bir olasılıklar dünyasının sunulma ihtimali gerçekten de tatlı. Benim durumumda, heyecanlıyım. Ancak benim heyecanım teknoloji (React) veya uygulama (Gutenberg) hakkında değil, yapı birimi olarak bileşenleri kullanarak siteler oluşturmak olan konsept hakkında. Gelecekte, uygulama Vue gibi başka bir platforma geçebilir, ancak konsept kalacaktır.

Hangi yeni özellikleri uygulayabileceğimizi öngörmek her zaman kolay değildir. Yeni bir paradigmaya uyum sağlamak zaman alır ve yeni araçları yeni hedeflere ulaşmak için nasıl kullanacağımızı anlayana kadar yeni araçları eski şekilde kullanma eğilimindeyiz. Web doğmadan önceki baskın teknoloji olan baskının bir temsili olan PDF dosyaları bile, web'in baskıya göre sahip olduğu avantajları göz ardı ederek web'de hala yaygın bir görüntüdür.

"Bilgisayar ekranındaki kağıdı taklit etmek, 747'nin kanatlarını koparıp onu otoyolda otobüs olarak kullanmak gibidir."

-Ted Nelson

Bu makalede, bileşen tabanlı bir mimari (kavram olarak) ve Gutenberg (uygulama olarak) aracılığıyla şantiyelerin hangi yeni işlevleri sunabileceği, mevcut web sitesi geliştirme ile ne kadar daha iyi entegre edilebileceği dahil olmak üzere çeşitli etkilerini analiz edeceğim. trendler ve WordPress'in geleceği için ne anlama geldiği.

Genişletilmiş Çok Yönlülük ve İçeriğin Kullanılabilirliği

Tüm içeriği bloklar olarak ele almanın çok önemli bir yan etkisi, HTML parçalarını tek tek hedeflemeye ve bunları farklı çıktılar için kullanmaya izin vermesidir. HTML bloğuna eklenen içeriğe yalnızca web sayfası üzerinden erişilebilirken, parçalar halinde bir API aracılığıyla erişilebilir ve meta verilerine kolayca erişilebilir. Video, ses veya görüntü gibi medya öğelerini alın. Bağımsız bir blok olarak, video bir uygulamada oynatılabilir, ses bir podcast olarak oynatılabilir ve bir özet gönderilirken görüntüler e-postaya eklenebilir - bunların tümü HTML kodunu ayrıştırmak zorunda kalmadan.

Benzer şekilde, bloklardan gelen içerik farklı ortamlar için uyarlanabilir: en küçük ekrandan en büyüğüne, dokunmatik ekran veya masaüstüne, sesle veya dokunarak komuta, 2D/AR/VR veya kim bilir geleceğin neler getirebileceğini. Örneğin, bir ses bloğu, sesin bir Apple Watch'ta, araç içi sistem veya bir AWS Echo aracılığıyla sesle komut verilen veya bir VR başlığı kullanılırken sanal dünyamızda kayan bir öğe olarak çalınmasına olanak tanır. Bloklar ayrıca, duyarlı bir web sitesi, AMP, mobil uygulama, e-posta veya başka herhangi bir çıktıda yayınlanacak içerik için NPR tarafından Create Once aracılığıyla yapıldığı gibi tek bir doğruluk kaynağı kurmayı da kolaylaştırabilir. , Publish Everywhere (COPE) yaklaşımı.

Not : Bu konular hakkında daha fazla bilgi için Karen McGrane'in İçeriğini Zombie Apocalypse konuşmasında izlemenizi öneririm.

Bloklar, kullanıcı deneyimini de iyileştirebilir. Siteye 3G üzerinden göz atıyorsanız, bloklar düşük kaliteli görüntüleri görüntülemek ve yükleme videolarını atlamak için yavaş bağlantı modunda kendi kendine oluşturulabilir. Veya, bir resim galerisini yalnızca makaleye gömülü olduğu yerde değil, web sayfasının herhangi bir noktasında tek bir tıklamayla göstermeyi teklif etmek gibi düzeni iyileştirebilir.

Bu deneyimler, içeriğin biçimden ayrılmasıyla elde edilebilir, bu da içeriğin sunumunun ve anlamının ayrıştırıldığı ve yalnızca anlamın veritabanına kaydedildiği, sunum verilerinin ikincil hale getirildiği ve başka bir yere kaydedildiği anlamına gelir. Semantik HTML bu kavramın bir ifadesidir: (karakterin italik olarak gösterilmesini sağlamak için) bir sunum biçimi olan <i> yerine her zaman anlamı ifade eden <em> kullanmalıyız, çünkü o zaman bu içerik ses gibi diğer ortamlar (Alexa italik okuyamaz, ancak cümleye vurgu ekleyebilir).

Sunum kodu genellikle HTML işaretlemesi yoluyla bloğun içine ekleneceğinden içeriğin biçimden kapsamlı bir şekilde ayrılmasını sağlamak çok zordur ("sağ çekme" sınıfı eklemek zaten sunum anlamına gelir). Bununla birlikte, siteyi bloklar kullanarak tasarlamak, yerleşim düzeyinde bir miktar ayrım düzeyine ulaşılmasına zaten yardımcı olur. Ek olarak, sadece bir şey yapmak ve bunu çok iyi yapmak için oluşturulan bloklar, uygun semantik HTML'yi kullanabilir, kendi mimarisinde HTML, JS ve CSS ile ilgili endişeleri iyi bir şekilde ayırabilir (böylece onları diğer platformlara taşımak için) minimum çaba gerektirebilir) ve en azından bileşen düzeyinde erişilebilir olmalıdır.

Not : Genel bir kural: Bir bileşen ne kadar kapsayıcıysa, henüz icat edilmemiş ortamlar için o kadar hazırlıklıdır.

Ne yazık ki, Gutenberg bu amaç düşünülerek tasarlanmamıştır, bu nedenle bloklar sunum için bol miktarda HTML işaretlemesi içerir. Örneğin, harici bir görüntüden gelen bir görüntü bloğu, anlamı olarak yalnızca görüntünün URL'sine, alternatif açıklamaya ve altyazıya (ve muhtemelen ayrıca genişlik ve yüksekliğe) sahiptir; bir görüntü bloğu oluşturduktan sonra, aşağıdaki kod parçası DB'ye kaydedildi (sınıf aligncenter merkezi sunum içindir ve <div class="wp-block-image" /> işaretlemesi yalnızca anlam depoluyorsa tamamen gereksiz olur):

 <!-- wp:image {"align":"center"} --> <div class="wp-block-image"> <figure class="aligncenter"> <img src="https://cldup.com/cXyG__fTLN.jpg" alt="Beautiful landscape"/> <figcaption>If your theme supports it, you'll see the "wide" button on the image toolbar. Give it a try.</figcaption> </figure> </div> <!-- /wp:image -->

Ek olarak, bloklar, her birinin veritabanında kendine ait bir girişi olması yerine, gönderinin içeriğinin (bu büyük bir HTML bloğudur) içine kaydedilir. Yeniden kullanılabilir blokların (aynı zamanda küresel bloklar olarak da adlandırılır) kendi girişleri vardır, bu da geliştiricilerin standart blokları yeniden kullanılabilir bloklara dönüştürebileceğinden korkmama neden olur, yalnızca hızlı bir saldırının onlara doğrudan DB'de erişmesi için.

Benzer şekilde, uygun şekilde tasarlanmadığı takdirde blokların sitelerimizde hasara bile yol açabileceğinden endişeleniyorum. Örneğin, farkında olmayan geliştiriciler, JavaScript'i yalnızca işlevsellik için değil, aynı zamanda CSS ve biçimlendirme için de kullanarak en az güç kuralını görmezden gelebilirler. Ek olarak, Gutenberg'in sunucu tarafı oluşturma (SSR) işlevi izomorfik değildir (yani, tek bir kod tabanının hem istemci hem de sunucu tarafı kodu için çıktı üretmesine izin vermez), bu nedenle dinamik blokların HTML kodunu oluşturmak için işlevi uygulaması gerekir. ayrıca aşamalı geliştirme sunmak için PHP olarak (ilk yüklenirken siteye erişilemez).

Özetle, bloklar WordPress içeriğini herhangi bir formatta ve herhangi bir ortamda kullanılabilir hale getirmek için doğru yönde atılmış bir adımdır, ancak kesin bir çözüm değildir, daha yapılması gereken çok iş var.

Verim

Performans önemlidir. Daha hızlı siteler daha mutlu kullanıcılara yol açar, bu da daha iyi dönüşüm oranlarına yol açar. Örneğin, Etsy'deki ekip, site yükleme sürelerinin kritik bir eşiği aşmasına neden oluyorsa, olabilecekleri kadar havalı yeni özellikler raflar (Allison McKnight'ın Uzun Vadeli Bina Performansı ve slaytlar hakkındaki konuşmasını izlemenizi tavsiye ederim). Twitter'daki ekip, içeriği mümkün olan en kısa sürede göstermek için sunucu tarafı oluşturmayı desteklemek için sitelerini birkaç yıl önce yeniden tasarladı ve hızlı bir kullanıcı deneyimi sunmak için sürekli olarak çok sayıda küçük değişiklik uyguluyor.

JavaScript geliştiriciler için çok çekici olduğundan, kullanımlarında herhangi bir kısıtlama yaşamazlar, bu gerçek bir sorundur: JavaScript performans açısından çok pahalıdır ve çok dikkatli kullanılmalıdır.

Şu anki haliyle Gutenberg optimal olmaktan uzaktır: eski düzenleyiciyle (Klasik Düzenleyiciyi yüklememiz gereken) bir gönderi oluşturmak yaklaşık 1,4 MB JavaScript yüklemeyi gerektirirken, Gutenberg yalnızca temel işlevi için yaklaşık 3,5 MB JavaScript yükler. deneyim (yani, herhangi bir ek blok yüklemeden):

Bu, şu anda olduğu gibi, 3.5 MB'ın taban çizgisi olduğu ve site yöneticisi daha fazla blok yükledikçe yükleme boyutunun yalnızca oradan artacağı anlamına gelir. Smashing Magazine'deki yakın tarihli bir makalede görüldüğü gibi, bir referans bloğu oluşturmak için 150 KB küçültülmüş JavaScript gerekliydi. Standart bir site kaç blok gerektirir? Ortalama bir sitenin kaç MB JavaScript indirmesi gerekecek?

Etkileri çoktur: Birincisi, ağır bir site, çoğunlukla yavaş bağlantılarla erişime sahip olan ve maaşlarının önemli bir bölümünü temsil eden veri planları satın alan sonraki milyar kullanıcıya erişemeyecek durumdadır. Onlar için her MB veri bir fark yaratır: Whatsapp mesajları göndermek uygun maliyetlidir, sadece bir siteyi yüklemek için birkaç MB'lık komut dosyası indirmek değildir.

Gutenberg, siteyi kullanmak için değil, sadece siteyi oluşturmak için olduğundan, web sitesinin kullanıcısının Gutenberg ile etkileşime girmesi gerekmeyeceği doğrudur: Gutenberg bir ön uç düzenleyici değil, bir arka uç düzenleyicidir (ve asla olmak - en azından WordPress çekirdeğinin bir parçası olarak). Ancak içerik oluşturucular cezalandırılacak ve onlar zaten büyük bir hedef. Ek olarak (daha önce tartıştığım gibi), kullanıcılar dinamik bloklar yoluyla da cezalandırılabilirler, bu da işaretlemelerini sunucu tarafı PHP yerine istemci tarafı JavaScript aracılığıyla oluşturabilir.

Ayrıca 3. taraf eklentiler tarafından eklenen yinelenen işlevlerden kaynaklanan şişkinlik sorunu da vardır. Eski günlerde, bir WordPress sitesi, düzeltilmesi nispeten kolay olan birkaç jQuery sürümü yüklemiş olabilir. Günümüzde, gerekli bir işlevi (sürükle ve bırak, takvimler, çoklu seçim bileşenleri, karusel vb.) uygulamak için aralarından seçim yapabileceğiniz çok sayıda açık kaynak kitaplığı vardır, bu nedenle düzinelerce 3. taraf bloğu olan bir site olmamasından çok daha olasıdır. farklı kitaplıklar tarafından uygulanan aynı işlevselliğe sahip olacak ve gereksiz şişkinlik yaratacaktır. Ek olarak, Gutenberg'in kendisine bir miktar şişkinlik eklendi: bloklar ön uçta kayıtlı olduğundan, zaten kayıtlı bir bloğun kaydının kaldırılması, ek bir komut dosyası yüklenerek yapılır. Benim düşünceme göre, bu Gutenberg katkıda bulunanlar için en büyük zorluklardan biri: herkesin (sadece Webpack ile deneyimli geliştiricilerin değil) istenmeyen kitaplıkları kaldırmasına ve yalnızca uygulama için gereken minimum kaynak kümesini paketlemesine izin veren basitleştirilmiş bir süreci devreye sokmak .

Son olarak, Gutenberg'in sunucu tarafı oluşturmayı desteklediğini tekrar belirtmek isterim, ancak bakımı kolay olmadığı için geliştiriciler buna güvenmemeye özendirilebilir. Bu durumda, yalnızca yerleşimi oluşturmak için REST uç noktalarından veri almak için gereken ek gidiş dönüşlerin maliyeti vardır, bu süre boyunca kullanıcının bekleyecektir.

Benim düşünceme göre, performans, yaygın olarak benimsenme açısından kazanabilecek veya kırılabilecek olan Gutenberg için en büyük zorluklardan biri olacak ve esas olarak Gutenberg'in bir site haline geldiği bir sonraki aşamayı hedefleyen, yapılması gereken çok sayıda iş var. inşaatçı.

Web Standartları

Daha önce bahsedildiği gibi, Gutenberg, düzgün bir şekilde uygulanırsa WordPress'in React'e kilitlenmesini önleyebilecek yapı taşlarına çerçeveden bağımsız bir yaklaşım sağlamak için React'i özetler. WordPress topluluğu, herhangi bir JavaScript çerçevesini WordPress çekirdeğiyle birleştirirken temkinlidir, çünkü büyük ölçüde Backbone.js, WordPress çekirdeğine eklendikten kısa bir süre sonra popülaritesinde keskin bir düşüş gördü ve Medya Yöneticisini güçlendirmek dışında pek çok özellik gerçekleştirilmedi. Bununla. React şu anda en popüler JavaScript kitaplığı olsa bile, bunun her zaman böyle olacağına inanmak için hiçbir neden yok (jQuery'nin çözülmesinin kanıtlayabileceği gibi) ve WordPress'in o gün nihayet geldiğinde (ki bu, hızlı olduğu göz önüne alındığında) hazır olması gerekir. teknolojinin hızı, beklenenden daha erken gerçekleşebilir).

Herhangi bir kitaplığa kilitlenmekten kaçınmanın en iyi yolu, web standartları ve daha özel olarak bu durumda, web bileşenleri aracılığıyla blokların uygulanmasıdır. Web bileşenleri, tarayıcı API'leri ile çalışan güçlü bir şekilde kapsüllenmiş bileşenlerdir, bu nedenle çalışmak için herhangi bir JavaScript kitaplığı gerektirmezler. Ancak, herhangi bir istemci tarafı JavaScript çerçevesi aracılığıyla uygulanabilirler.

React henüz web bileşenleriyle kusursuz bir entegrasyon sağlamasa da, sonunda (veya daha doğrusu umarız) sağlayacaktır. React'in belgelerinde açıklandığı gibi, web bileşenleri ve React bileşenleri birlikte çalışabilir:

“React ve Web Components, farklı sorunları çözmek için geliştirildi. Web Bileşenleri, yeniden kullanılabilir bileşenler için güçlü bir kapsülleme sağlarken, React, DOM'yi verilerinizle senkronize tutan bildirime dayalı bir kitaplık sağlar. İki hedef birbirini tamamlıyor. Bir geliştirici olarak, Web Bileşenlerinizde React'i kullanmakta veya React'te Web Bileşenlerini kullanmakta veya her ikisinde de özgürsünüz."

Bugün itibariyle, bu durumun gerçekleşmesi pek umut verici görünmüyor: Web bileşenlerine sahip yapı taşları için herhangi bir eğitim bulamadım. Topluluğun, geliştiricileri web bileşenleri kullanarak yapı taşları oluşturmaya teşvik ederek ve Gutenberg bizi her halükarda yeni teknolojileri öğrenmeye zorladığı için ne kadar erken olursa o kadar iyi olacak şekilde, bu amaç için biraz çaba harcaması gerektiğine inanıyorum. En başından itibaren web standartlarıyla güçlü bir temel oluşturmak için bir fırsattır.

Siteler Arası Birlikte Çalışabilirlik, Sitelerin Homojenizasyonu

Bir blok, bir tema veya eklentiden daha küçük bir varlıktır, bu nedenle sonunda bloklara kendi başlarına erişilebilir ve yeni oluşturulan blok pazarları aracılığıyla edinilir. Ekosistemdeki birçok oyuncunun çözümlerini ilk pazarlayan olmak için acele etmesi ve orta ve uzun vadede en başarılı olanların konsolidasyonuna yol açması nedeniyle, büyük olasılıkla başlangıçta bir Kambriyen blok patlaması olacaktır.

Toz çöktüğünde, birkaç blok öne çıkacak ve kazananlar olacak ve belirli kategorilerinde pazarın çoğunu elde edecek. Bu olursa/ne zaman olursa, hem endişe hem de sevinç nedeni olacaktır: aynı bileşenleri kullanan siteler aynı görünüm ve his ile sonuçlanabileceğinden, web'in yeni bir homojenleştirme dalgasının (Bootstrap'ta olduğu gibi) gerçekleşmesiyle ilgili endişe , yeni fırsatların kapılarını açabilecek aynı bileşenlere ve aynı API'lere dayanan siteler arasında artan birlikte çalışabilirlik hakkında bir sevinç.

Siteler arasında birlikte çalışabilirliği genişletme konusunda özellikle heyecanlıyım. Bu, uzun vadede, Facebook gibi krallıkları geri alabilecek bir alandır: bilgi paylaşımı için tekelci bir ağ geçidine güvenmek yerine, farklı topluluklara sahip siteler, verileri kendi aralarında doğrudan paylaşabilir. Bu yeni bir kavram değil: IndieWeb hareketi, web sitelerinin mikro formatlar aracılığıyla birbirleriyle konuşmasını sağlayarak, herkesin kendi sunucularında kendi verilerine sahip olmasını sağlamak için uzun süredir çalışıyor. Örneğin, Webmention web standartları, her bir yorum ve yanıtın her ikisinde de saklandığı iki sitenin bir görüşme yapmasına izin verir ve Micro.blog bir tür Twitter sunar, ancak açık web'e dayalıdır. kullanıcının zaman çizelgesinde, abone olunan sitelerden RSS ve JSON beslemelerinden toplanır. Bu çabalar harika, ancak yine de etkileri çok küçük, çünkü bunların bir parçası olmak için bir miktar teknoloji bilgisi gerekiyor. Gutenberg'in bileşen tabanlı mimarisi, potansiyel olarak çok daha geniş bir etki yaratabilir: Popüler bloklar, çok sayıda WordPress sitesinin birbiriyle konuşmasını sağlayabilir ve sonunda web'deki tüm sitelerin %30'una kadarının merkezi olmayan, gevşek bir şekilde bağlanmış bir ağın parçası olmasına izin verebilir. .

Bu alan, uygulanabilir olmadan önce çok fazla çalışmaya ihtiyaç duyacaktır. Bu amaç için tasarlanmadıkları için varsayılan REST uç noktalarının en iyi iletişim arabirimi olduğunu düşünmüyorum (micro.blog'daki kişiler RSS belirtimine dayanan JSON arabirimleri aracılığıyla daha iyi bir çözüm önerdiler). Ek olarak, REST, GraphQL tarafından geçersiz kılınıyor, bu yüzden uzun vadede ona büyük umutlar vermem. Ayrıca, şu anda tüm gerekli verileri tek bir istekte alabilen ve bileşen tabanlı bir mimari aracılığıyla genişletilebilirliği destekleyen farklı bir API türü üzerinde çalıştığım daha iyi bir yol bulmakla ilgileniyorum.

Ayrıca, sağlayıcılar kendi hizmetleriyle etkileşim kurmak için kendi bloklarını yayınlayabildiklerinden, bulut hizmetleriyle entegrasyonun daha belirgin olmasını bekliyorum. Bir bileşen bağımsız bir birim olduğundan, bloğu sayfaya sürükleyip bırakarak zaten tüm işi kullanıcının bakış açısından yapıyor ve çok az bilgiyle veya hiç bilgi olmadan güçlü web siteleri oluşturmayı çok kolaylaştırıyor. Örneğin, Cloudinary gibi bir görüntü depolama sağlayıcısı, görüntüyü cihazın görünüm alanına göre otomatik olarak kırpan bir blok yayınlayabilir veya destekleniyorsa görüntüyü WebP olarak veya başka kullanım durumları olarak talep edebilir.

Özetle, blok pazarın konsolidasyonu, nasıl göründüğü ve hissettirdiği konusunda homojenleşme sağlayabilir, ki bu üzücü bir olay olur ve kaçınılması gerekir ve birlikte çalışabilirlik ve siteler arasında veri paylaşımı ve bulut hizmetleri ile entegrasyon ile ilgili güçlü yetenekler getirebilir.

Kalıp Kitaplıkları ile Entegrasyon

Bir kalıp kitaplığı, her biri genellikle HTML, JS ve CSS parçacıklarından oluşan kullanıcı arabirimi tasarım öğelerinin bir koleksiyonudur. Blok, genellikle HTML, JS ve CSS parçalarından oluşan özerk bir bileşendir. Bu nedenle bloklar, model kitaplıklarıyla belgelenmeye/oluşturulmaya açıkça uygundur. Blokların kalıp kitaplıklarını göndermesi, ekiplerin sitenin kalıp kitaplığını yalnızca site düzeyinde değil, gerekli tüm bloklardan mini kalıp kitaplıklarının bir araya getirilmesi ve iyileştirilmesi olarak uygulamaya başlamasını sağlayabileceğinden çok iyi olurdu.

Bu durumda, UI/UX/Documentation ile ilgili olarak, daha önce bahsettiğim bloatless JavaScript paketleri üretmeye yönelik düzene koyma sürecine benzer bir şeyin gerçekleştiğine inanıyorum. Blok geliştiricilerin blokları için kalıp kitaplıkları oluşturmasını kolaylaştıran ve hepsi bir araya toplandığında site için tutarlı bir kalıp kitaplığı ile sonuçlanabilecek bir süreci uygulamaya koymak, Gutenberg'e katkıda bulunanlar için hem bir zorluk hem de bir fırsat olacaktır. İyi bir şekilde uygulandığında, bu özellik, bir dokümantasyon/bakım perspektifinden şantiye maliyetlerini azaltabilir.

WordPress Ne Olacak?

Gutenberg, herkesin üstesinden gelemeyeceği gerekli bir uzmanlık düzeyi pahasına olsa da, web sitelerini kesinlikle daha çekici hale getirecektir. Uzun vadede, bu daha yüksek kaliteye, daha düşük miktara yol açabilir. WordPress'in "Yayıncılığı Demokratikleştirme" özdeyişinden yola çıkarak, bu bir sorun haline gelebilir.

Gutenberg konusunda hevesliyim, ancak React tabanlı uygulamadan daha çok bileşen tabanlı bir mimari kavramı olarak. Genel anlamda, Matt Mullenweg'in WordCamp Europe 2018 sırasında Gutenberg'i haklı çıkarmak için söylediklerine katılıyorum:

"Bize on beş yıl boyunca iyi hizmet eden WordPress'in temeli, önümüzdeki on beş yıl boyunca sürmeyecek."

Bununla birlikte, on beş yıllık geleceğin WordPress'inin bugün bildiğimizden tamamen farklı olabileceğine de inanıyorum. WordPress'in öncelikle müşteri tabanlı editör olup olmayacağını merak ediyorum ve çok daha fazlası değil: Gutenberg'i açık web'in editörü yapmak amacıyla Gutenberg'i Drupal'a entegre etme girişimi, WordPress'i başsız bir CMS işletim sistemi olarak resmileştirecek. REST uç noktaları aracılığıyla. Bu kendi başına iyi bir gelişmedir, ancak WordPress'i arka uçtan vazgeçilebilir hale getirecektir: Başka herhangi bir arka uç platformu daha iyi özellikler sağlıyorsa, artık WordPress arka ucuna bağlı kalmak için hiçbir neden yoktur. Sonuçta, istemci tarafı Gutenberg bunlardan herhangi biriyle çalışabilecekken, WordPress ile bir site oluşturmanın basitliği kaybolacak ve oyun alanını diğer tüm platformlarla aynı seviyeye getirecek.

Özellikle, geliştiriciler, dinamik blokları oluşturmak için iki kod tabanını (biri JavaScript'te ve diğeri PHP'de) korumanın çok zor olduğunu düşünürse ve izomorfik sunucu tarafı oluşturmayı destekleyen platformlara geçmeye karar verirse şaşırmam. Bu senaryo gerçekten gerçekleşirse Matt, WordPress arka ucunu Node.js'ye kaydırmaya karar verir mi?

Esasen bu sorundan dolayı, bundan 15 yıl sonra WordPress'in günümüzde olduğundan çok farklı bir varlık olabileceğini söylemeye cesaret ediyorum. Ne olacağını kim bilir?

Çözüm

Bileşenleri şantiyeler için yeni birim yaparak, Gutenberg'in tanıtımı WordPress'e dönüşüm sağlayacak. Ve herhangi bir paradigma değişiminde olduğu gibi, kazananlar ve kaybedenler olacaktır. Farklı paydaşlar, kendi durumlarına bağlı olarak Gutenberg'i olumlu veya olumsuz bir gelişme olarak değerlendireceklerdir: Bir web sitesinin kalitesi yükselirken, karmaşıklığını kaldırabilecek geliştiriciler işe alarak böyle bir site kurmanın fiyatı da yükselecek ve bu da onu daha az uygun hale getirecektir. ve daha az popüler.

Bunlar heyecan verici zamanlar ama aynı zamanda önemli zamanlar. Şu andan itibaren, WordPress yavaş yavaş alıştığımızdan farklı bir varlık olmaya başlayabilir ve sonunda WordPress'in ne olduğunu ve neyi temsil ettiğini yeniden düşünmemiz gerekebilir.