ผลกระทบของการคิดในบล็อกแทนที่จะเป็น Blobs

Gutenberg เป็นตัวแก้ไขที่ใช้ JavaScript (โดยเฉพาะอย่างยิ่งคือตัวแก้ไขที่ใช้ React) ซึ่งเร็ว ๆ นี้จะเปลี่ยนประสบการณ์ในการสร้างเนื้อหาสำหรับ WordPress และ (บนเวทีที่จะเกิดขึ้นเมื่อ Gutenberg ถูกเปลี่ยนเป็นผู้สร้างไซต์) ประสบการณ์ในการสร้าง ไซต์เวิร์ดเพรส

Gutenberg ผู้สร้างเว็บไซต์จะต้องการวิธีคิดที่แตกต่างออกไปในการวางรากฐานของเว็บไซต์ ในสิ่งที่เราสามารถเรียกว่าโมเดล "เก่า" ได้แล้ว ไซต์ WordPress ถูกสร้างขึ้นโดยให้โครงสร้างผ่านเทมเพลต ( header.php , index.php , sidebar.php , footer.php ) และดึงเนื้อหาบนหน้าจากหยดเดียว ของโค้ด HTML ในรูปแบบใหม่ หน้ามีองค์ประกอบ (ตอบสนอง) วางอยู่ทั่วหน้า แต่ละองค์ประกอบควบคุมตรรกะของตนเอง โหลดข้อมูลของตนเอง และแสดงผลด้วยตนเอง

เพื่อชื่นชมการเปลี่ยนแปลงที่จะเกิดขึ้นทางสายตา WordPress กำลังย้ายจากสิ่งนี้:

…สำหรับสิ่งนี้:

ฉันเชื่อว่าการเปลี่ยนจาก blobs ของโค้ด HTML ไปเป็นส่วนประกอบสำหรับการสร้างไซต์นั้นไม่ได้เป็นเพียงการเปลี่ยนกระบวนทัศน์ ผลกระทบของ Gutenberg เป็นมากกว่าการเปลี่ยนจาก PHP เป็น JavaScript: มีบางสิ่งที่สามารถทำได้ในอดีตซึ่งอาจจะไม่สมเหตุสมผลอีกต่อไป ในทำนองเดียวกัน โลกใหม่ของความเป็นไปได้ก็เปิดออก เช่น การโต้ตอบกับผู้ใช้ที่สมบูรณ์และทรงพลัง นักพัฒนาเว็บจะไม่เปลี่ยนจากการสร้างไซต์ในภาษาหนึ่งไปเป็นการสร้างไซต์ในภาษาอื่น เนื่องจากไซต์จะไม่เหมือนเดิมอีกต่อไป มันจะเป็นไซต์ที่แตกต่างอย่างสิ้นเชิงที่จะสร้าง

การอ่านที่แนะนำ : กายวิภาคที่สมบูรณ์ของ Gutenberg WordPress Editor

Gutenberg ยังไม่ได้รับการยอมรับอย่างเต็มที่จากชุมชน WordPress ด้วยเหตุผลหลายประการ ประการหนึ่ง สถาปัตยกรรมใหม่นี้อาศัยเครื่องมือและเทคโนโลยีมากมาย (React, NPM, Webpack, Redux และอื่นๆ) ซึ่งยากต่อการเรียนรู้และเชี่ยวชาญมากกว่าสถาปัตยกรรมที่ใช้ PHP แบบเก่า และถึงแม้ว่ามันอาจจะคุ้มค่าที่จะเรียนรู้สแต็กใหม่ที่มีฟังก์ชันการทำงานใหม่ แต่ไซต์ Mom&pop ทุกแห่งก็ไม่ต้องการคุณสมบัติใหม่ที่สวยงามเหล่านี้

ไม่ใช่เรื่องบังเอิญที่ 30% ของไซต์ทั้งหมดทั่วโลกเป็นไซต์ WordPress: ส่วนใหญ่เป็นไซต์ที่เรียบง่ายจริงๆ เช่น บล็อก ไม่ใช่เครือข่ายโซเชียลแบบไดนามิกเช่น Facebook อีกประการหนึ่ง ความครอบคลุมของ WordPress หมายความว่าทุกคนสามารถสร้างเว็บไซต์ที่เรียบง่ายได้ แม้กระทั่งผู้ที่ไม่มีประสบการณ์ในการเขียนโค้ด เช่น นักออกแบบ นักการตลาดเนื้อหา และบล็อกเกอร์

แต่ความซับซ้อนของสถาปัตยกรรมใหม่จะทำให้คนจำนวนมากไม่อยู่ (ฉันไม่ต้องการที่จะคิดเกี่ยวกับการดีบักไซต์ของฉันในโค้ด JavaScript ที่ย่อขนาด) และอีกอย่าง เมื่อ Gutenberg เผยแพร่แล้ว React ที่สนับสนุนโดย Facebook จะถูกเพิ่มลงในเว็บไซต์มากถึง 30% ของโลก — ในชั่วข้ามคืน หลายคนรู้สึกไม่สบายใจที่จะให้พลังมากมายกับไลบรารี JavaScript ทุกประเภท ในขณะที่อีกหลายคนไม่ไว้วางใจ Facebook เพื่อบรรเทาข้อกังวลนี้ Gutenberg abstracts React เพื่อเปิดใช้งานการเข้ารหัสในเฟรมเวิร์กหรือไลบรารีอื่น ๆ อย่างไรก็ตามในทางปฏิบัติ React จะเป็นไลบรารี JavaScript ที่โดดเด่นอย่างไม่ต้องสงสัย

กระนั้น โอกาสที่จะได้รับการเสนอโลกแห่งความเป็นไปได้ใหม่นั้นช่างหอมหวานจริงๆ ในกรณีของฉัน ฉันตื่นเต้น อย่างไรก็ตาม ความตื่นเต้นของฉันไม่ได้เกี่ยวกับเทคโนโลยี (React) หรือเกี่ยวกับการใช้งาน (Gutenberg) แต่เกี่ยวกับแนวคิดคือการสร้างไซต์โดยใช้ส่วนประกอบเป็นหน่วยอาคาร ในอนาคต การใช้งานอาจเปลี่ยนไปใช้แพลตฟอร์มอื่น เช่น Vue แต่แนวคิดจะยังคงอยู่

การคาดการณ์ล่วงหน้าว่าคุณลักษณะใหม่ใดบ้างที่เราจะสามารถนำมาใช้ได้นั้นไม่ใช่เรื่องง่ายเสมอไป ต้องใช้เวลาในการปรับให้เข้ากับกระบวนทัศน์ใหม่ และเรามักจะใช้เครื่องมือใหม่ด้วยวิธีเดิม จนกระทั่งเริ่มเข้าใจถึงวิธีการใช้เครื่องมือใหม่เพื่อให้บรรลุวัตถุประสงค์ใหม่ แม้แต่ไฟล์ PDF (ซึ่งเป็นตัวแทนของการพิมพ์ ซึ่งเป็นเทคโนโลยีที่โดดเด่นก่อนเกิดเว็บ) ก็ยังคงพบเห็นได้ทั่วไปบนเว็บ โดยมองข้ามข้อดีที่เว็บมีมากกว่าการพิมพ์

“กระดาษลอกเลียนแบบบนหน้าจอคอมพิวเตอร์ก็เหมือนกับการฉีกปีกของเครื่องบินรุ่น 747 แล้วใช้เป็นรถบัสบนทางหลวง”

— เท็ดเนลสัน

ในบทความนี้ ผมจะวิเคราะห์ความหมายหลายๆ อย่างของการสร้างไซต์ผ่านสถาปัตยกรรมแบบส่วนประกอบ (ตามแนวคิด) และผ่าน Gutenberg (เมื่อใช้งาน) รวมถึงฟังก์ชันใหม่ๆ ที่สามารถนำเสนอได้ ว่าสามารถผสานรวมกับการพัฒนาเว็บไซต์ในปัจจุบันได้ดีเพียงใด แนวโน้มและความหมายต่ออนาคตของ WordPress

ความหลากหลายและความพร้อมใช้งานของเนื้อหาที่เพิ่มขึ้น

ผลข้างเคียงที่สำคัญมากของการปฏิบัติต่อเนื้อหาทั้งหมดเสมือนเป็นบล็อกคือ อนุญาตให้กำหนดเป้าหมายส่วน HTML ทีละรายการและใช้สำหรับผลลัพธ์ที่ต่างกัน ในขณะที่เนื้อหาที่แทรกลงใน HTML blob สามารถเข้าถึงได้ผ่านทางหน้าเว็บเท่านั้น เนื่องจากสามารถเข้าถึงชิ้นส่วนต่างๆ ได้ผ่าน API และข้อมูลเมตาของเนื้อหานั้นพร้อมใช้งาน นำองค์ประกอบสื่อ เช่น วิดีโอ เสียง หรือรูปภาพ วิดีโอสามารถเล่นในแอป เสียงสามารถเล่นเป็นพ็อดคาสท์ และสามารถแนบรูปภาพไปกับอีเมลเมื่อส่งไดเจสต์ ทั้งหมดนี้โดยไม่ต้องแยกวิเคราะห์โค้ด HTML

ในทำนองเดียวกัน เนื้อหาจากบล็อกสามารถปรับให้เข้ากับสื่อต่างๆ ได้ ตั้งแต่หน้าจอที่เล็กที่สุดไปจนถึงหน้าจอที่ใหญ่ที่สุด หน้าจอสัมผัสหรือเดสก์ท็อป คำสั่งด้วยเสียงหรือการสัมผัส 2D/AR/VR หรือใครจะรู้ว่าอนาคตจะเกิดอะไรขึ้น ตัวอย่างเช่น บล็อกเสียงอนุญาตให้เล่นเสียงบน Apple Watch สั่งด้วยเสียงผ่านระบบในรถยนต์หรือ AWS Echo หรือเป็นรายการลอยตัวในโลกเสมือนจริงของเราเมื่อใช้ชุดหูฟัง VR บล็อกยังช่วยให้ตั้งค่าแหล่งความจริงเพียงแหล่งเดียวได้ง่ายขึ้นสำหรับเนื้อหาที่จะเผยแพร่ในเอาต์พุตต่างๆ เช่น เว็บไซต์ที่ตอบสนอง AMP แอปบนอุปกรณ์เคลื่อนที่ อีเมล หรืออื่นๆ ตามที่ NPR ทำผ่าน Create Once , แนวทางการเผยแพร่ทุกที่ (COPE)

หมายเหตุ : สำหรับข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อเหล่านี้ ฉันแนะนำให้ดูเนื้อหาของ Karen McGrane ในการพูดคุยเรื่อง Zombie Apocalypse

บล็อกสามารถปรับปรุงประสบการณ์ผู้ใช้ได้เช่นกัน หากเรียกดูเว็บไซต์ผ่าน 3G บล็อกสามารถแสดงผลด้วยตนเองในโหมดการเชื่อมต่อช้าเพื่อแสดงภาพคุณภาพต่ำและข้ามการโหลดวิดีโอ หรืออาจปรับปรุงเลย์เอาต์ เช่น เสนอให้แสดงแกลเลอรีรูปภาพด้วยการคลิกเพียงครั้งเดียวที่จุดใดก็ได้ของหน้าเว็บ ไม่ใช่เฉพาะที่ที่ฝังอยู่ในบทความ

ประสบการณ์เหล่านี้สามารถบรรลุได้โดยการแยกเนื้อหาออกจากแบบฟอร์ม ซึ่งหมายความว่าการนำเสนอและความหมายของเนื้อหาแยกจากกัน และมีเพียงความหมายเท่านั้นที่บันทึกไว้ในฐานข้อมูล ทำให้ข้อมูลการนำเสนอเป็นข้อมูลรองและบันทึกไว้ในที่อื่น Semantic HTML เป็นนิพจน์ของแนวคิดนี้ เราควรใช้ <em> ซึ่งหมายถึงความหมาย แทนที่จะเป็น <i> ซึ่งเป็นรูปแบบการนำเสนอ (เพื่อให้แสดงอักขระเป็นตัวเอียง) เพราะเนื้อหานี้จะพร้อมใช้งาน สื่ออื่นๆ เช่น เสียง (Alexa ไม่สามารถอ่านตัวเอียงได้ แต่เธอสามารถเน้นย้ำประโยคได้)

การแยกเนื้อหาออกจากแบบฟอร์มอย่างละเอียดเป็นเรื่องยากมาก เนื่องจากโค้ดการนำเสนอมักจะถูกเพิ่มเข้าไปในบล็อก ผ่านมาร์กอัป HTML (การเพิ่มคลาส "pull-right" หมายถึงการนำเสนอแล้ว) อย่างไรก็ตาม การออกแบบเว็บไซต์โดยใช้บล็อกช่วยให้มีการแยกระดับในระดับเลย์เอาต์ได้ในระดับหนึ่ง นอกจากนี้ บล็อกที่สร้างขึ้นเพื่อทำสิ่งเดียวเท่านั้น และทำได้ดีมาก สามารถใช้ HTML เชิงความหมายที่เหมาะสม มีการแยกข้อกังวลที่ดีในสถาปัตยกรรมของตนเองเกี่ยวกับ HTML, JS และ CSS (เพื่อย้ายไปยังแพลตฟอร์มอื่น อาจต้องใช้ความพยายามขั้นต่ำเท่านั้น) และสามารถเข้าถึงได้ อย่างน้อยก็ในระดับส่วนประกอบ

หมายเหตุ : หลักการทั่วไป: ยิ่งส่วนประกอบมีความครอบคลุมมากเท่าไร ก็ยิ่งมีการเตรียมพร้อมสำหรับสื่อที่ยังไม่ได้ประดิษฐ์ขึ้นเท่านั้น

น่าเสียดายที่ Gutenberg ไม่ได้ออกแบบโดยคำนึงถึงจุดประสงค์นี้ ดังนั้นบล็อกจึงมีมาร์กอัป HTML สำหรับการนำเสนอจำนวนมากด้วย ตัวอย่างเช่น บล็อกรูปภาพจากรูปภาพภายนอก ตามความหมายแล้ว มีเพียง URL ของรูปภาพ คำอธิบาย alt และคำอธิบายภาพ (และอาจรวมถึงความกว้างและความสูงด้วย) หลังจากสร้างบล็อกรูปภาพ ส่วนของโค้ดต่อไปนี้ถูกบันทึกไว้ใน DB (คลาส aligncenter ใช้สำหรับการนำเสนอ และมาร์กอัป <div class="wp-block-image" /> จะซ้ำซ้อนโดยสิ้นเชิงหากจัดเก็บความหมายเท่านั้น):

 <!-- 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 -->

นอกจากนี้ บล็อกจะถูกบันทึกไว้ในเนื้อหาของโพสต์ (ซึ่งเป็น HTML blob ขนาดใหญ่) แทนที่จะมีรายการของตัวเองในฐานข้อมูล บล็อกที่นำกลับมาใช้ใหม่ได้ (หรือที่เรียกว่าบล็อกทั่วโลก) มีรายการของตัวเองซึ่งทำให้ฉันกลัวว่านักพัฒนาอาจแปลงบล็อกมาตรฐานเป็นบล็อกที่นำกลับมาใช้ใหม่ได้เพียงเพื่อแฮ็คอย่างรวดเร็วเพื่อเข้าถึงโดยตรงในฐานข้อมูล

ในทำนองเดียวกัน ฉันกังวลว่าหากไม่ได้ออกแบบมาอย่างเหมาะสม การบล็อกอาจทำให้ไซต์ของเราเสียหายได้ ตัวอย่างเช่น นักพัฒนาที่ไม่รู้จักอาจเพิกเฉยต่อกฎเกณฑ์ที่ใช้พลังงานน้อยที่สุด โดยใช้ JavaScript ไม่ใช่แค่สำหรับการทำงานเท่านั้น แต่ยังรวมถึง CSS และมาร์กอัปด้วย นอกจากนี้ ฟังก์ชันการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) ของ Gutenberg ไม่ใช่ isomorphic (กล่าวคือ ไม่อนุญาตให้ codebase เดียวสร้างเอาต์พุตสำหรับทั้งโค้ดฝั่งไคลเอ็นต์และเซิร์ฟเวอร์) ดังนั้นบล็อกแบบไดนามิกจึงต้องใช้งานฟังก์ชันเพื่อสร้างโค้ด HTML เช่นเดียวกับ PHP เพื่อนำเสนอการเพิ่มประสิทธิภาพแบบก้าวหน้า (โดยที่ไซต์ไม่สามารถเข้าถึงได้ในขณะที่โหลดในตอนแรก)

โดยสรุป บล็อกเป็นขั้นตอนในทิศทางที่ถูกต้องในการทำให้เนื้อหา WordPress พร้อมใช้งานในทุกรูปแบบและสำหรับสื่อใดๆ แต่สิ่งเหล่านี้ไม่ใช่วิธีแก้ปัญหาขั้นสุดท้าย ยังต้องทำงานอีกมาก

ผลงาน

ประสิทธิภาพเป็นเรื่องสำคัญ ไซต์ที่เร็วขึ้นทำให้ผู้ใช้มีความสุขมากขึ้น ซึ่งนำไปสู่อัตราการแปลงที่ดีขึ้น ตัวอย่างเช่น ทีมงานของ Etsy วางชั้นวางคุณลักษณะใหม่ ๆ ให้เจ๋งที่สุดเท่าที่จะทำได้ หากสิ่งเหล่านี้ทำให้เวลาในการโหลดไซต์เกินเกณฑ์ที่สำคัญ (ฉันแนะนำให้ดูการพูดคุยของ Allison McKnight เกี่ยวกับการสร้างประสิทธิภาพสำหรับระยะยาวและสไลด์) ในขณะที่ ทีมงานของ Twitter ได้ออกแบบเว็บไซต์ใหม่เมื่อหลายปีก่อนเพื่อรองรับการเรนเดอร์ฝั่งเซิร์ฟเวอร์เพื่อแสดงเนื้อหาโดยเร็วที่สุด และใช้การเปลี่ยนแปลงเล็กๆ น้อยๆ จำนวนมากอย่างต่อเนื่องเพื่อมอบประสบการณ์การใช้งานที่รวดเร็วแก่ผู้ใช้

JavaScript เป็นที่น่าสนใจมากสำหรับนักพัฒนา พวกเขาไม่มีข้อจำกัดในการใช้งาน ซึ่งเป็นปัญหาที่แท้จริง: JavaScript มีราคาแพงมากเกี่ยวกับประสิทธิภาพ และควรใช้อย่างระมัดระวัง

ขณะนี้ Gutenberg ยังห่างไกลจากความเหมาะสม: ในขณะที่การสร้างโพสต์ด้วยตัวแก้ไขเก่า (ซึ่งเราต้องติดตั้ง Classic Editor) จำเป็นต้องโหลด JavaScript ประมาณ 1.4 MB Gutenberg โหลด JavaScript ประมาณ 3.5 MB สำหรับพื้นฐาน ประสบการณ์ (นั่นคือโดยไม่ต้องติดตั้งบล็อกเพิ่มเติม):

นั่นหมายความว่า ณ ตอนนี้ 3.5 MB เป็นพื้นฐาน และขนาดการโหลดจะเพิ่มขึ้นจากที่นั่นเมื่อผู้ดูแลไซต์ติดตั้งบล็อกมากขึ้นเท่านั้น ดังที่เห็นในบทความล่าสุดบน Smashing Magazine การสร้างบล็อกคำรับรองต้องใช้ JavaScript ย่อขนาด 150KB ไซต์มาตรฐานต้องการบล็อกกี่บล็อก ไซต์เฉลี่ยต้องดาวน์โหลด JavaScript กี่ MB

ความหมายมีหลายประการ: ประการแรก ไซต์ขนาดใหญ่ไม่สามารถเข้าถึงได้สำหรับผู้ใช้อีกพันล้านราย ที่เข้าถึงได้เป็นส่วนใหญ่ในการเชื่อมต่อที่ช้า และผู้ที่ซื้อแผนข้อมูลซึ่งแสดงถึงรายได้ก้อนใหญ่ของพวกเขา สำหรับพวกเขา ทุก MB ของข้อมูลสร้างความแตกต่าง: การส่งข้อความ Whatsapp นั้นไม่แพง การดาวน์โหลดสคริปต์หลาย MB เพื่อโหลดไซต์เดียวไม่สามารถทำได้

เป็นความจริงที่ผู้ใช้เว็บไซต์ไม่จำเป็นต้องโต้ตอบกับ Gutenberg เนื่องจาก Gutenberg เป็นเพียงการสร้างเว็บไซต์ ไม่ใช่เพื่อการใช้งาน: Gutenberg เป็นโปรแกรมแก้ไขส่วนหลัง ไม่ใช่โปรแกรมแก้ไขส่วนหน้า (และไม่มีวัน เป็น — อย่างน้อยก็เป็นส่วนหนึ่งของแกนหลักของ WordPress) อย่างไรก็ตาม ผู้สร้างเนื้อหาจะถูกลงโทษ และพวกเขาก็เป็นเป้าหมายที่ใหญ่โตอยู่แล้ว นอกจากนี้ (อย่างที่ฉันเถียงไปก่อนหน้านี้) ผู้ใช้อาจถูกลงโทษเช่นกันผ่านบล็อกไดนามิก ซึ่งอาจสร้างมาร์กอัปผ่าน JavaScript ฝั่งไคลเอ็นต์แทน PHP ฝั่งเซิร์ฟเวอร์

นอกจากนี้ยังมีปัญหาเรื่องการขยายตัวจากการทำงานซ้ำซ้อนที่เพิ่มโดยปลั๊กอินของบุคคลที่สาม ในสมัยก่อน ไซต์ WordPress อาจโหลด jQuery หลายเวอร์ชัน ซึ่งแก้ไขได้ค่อนข้างง่าย ทุกวันนี้ มีไลบรารีโอเพ่นซอร์สมากมายให้เลือกเพื่อใช้งานฟังก์ชันที่จำเป็น (การลากและวาง ปฏิทิน ส่วนประกอบแบบเลือกได้หลายแบบ ภาพหมุน ฯลฯ) มีโอกาสมากกว่าเว็บไซต์ที่มีบล็อกของบุคคลที่สามหลายสิบบล็อก จะมีฟังก์ชันการทำงานเหมือนกันโดยไลบรารีต่างๆ ทำให้เกิดการขยายตัวที่ไม่จำเป็น นอกจากนี้ ยังมีการเพิ่มจำนวนเล็กน้อยใน Gutenberg ด้วย เนื่องจากบล็อกมีการลงทะเบียนในส่วนหน้า การยกเลิกการลงทะเบียนบล็อกที่ลงทะเบียนแล้วทำได้โดยการโหลดสคริปต์เพิ่มเติม ในความเห็นของฉัน นี่เป็นหนึ่งในความท้าทายที่ยิ่งใหญ่ที่สุดสำหรับผู้มีส่วนร่วมของ Gutenberg: เพื่อสร้างกระบวนการที่คล่องตัวที่ช่วยให้ทุกคน (ไม่ใช่แค่นักพัฒนาที่มีประสบการณ์กับ Webpack) สามารถลบไลบรารีที่ไม่ต้องการและจัดแพ็คเกจเฉพาะชุดทรัพยากรขั้นต่ำที่จำเป็นสำหรับแอปพลิเคชัน .

สุดท้ายนี้ ฉันขอพูดอีกครั้งว่า Gutenberg รองรับการเรนเดอร์ฝั่งเซิร์ฟเวอร์ แต่เนื่องจากการดูแลรักษาอาจไม่ง่าย นักพัฒนาจึงอาจไม่อยากพึ่งพา ในกรณีนี้ มีค่าใช้จ่ายสำหรับการเดินทางไปกลับเพิ่มเติมที่จำเป็นในการรับข้อมูลจากปลายทาง REST เพียงเพื่อแสดงเค้าโครง ในช่วงเวลาที่ผู้ใช้จะรอ

ในความเห็นของฉัน การแสดงจะเป็นหนึ่งในความท้าทายที่สำคัญสำหรับ Gutenberg ซึ่งสามารถสร้างหรือทำลายในแง่ของการยอมรับอย่างกว้างขวาง และยังมีงานอีกมากที่ควรทำ โดยมุ่งเป้าหมายไปที่ขั้นตอนต่อไปเมื่อ Gutenberg กลายเป็นไซต์ ผู้สร้าง

มาตรฐานเว็บ

ดังที่ได้กล่าวไว้ก่อนหน้านี้ Gutenberg ได้ทำการสรุป React เพื่อให้แนวทางที่ไม่เชื่อเรื่องพระเจ้าในกรอบงานสำหรับการสร้างบล็อค ซึ่งหากดำเนินการอย่างเหมาะสม สามารถหลีกเลี่ยง WordPress ที่จะถูกล็อคเพื่อตอบโต้ ชุมชน WordPress นั้นระมัดระวังเมื่อรวมเฟรมเวิร์ก JavaScript ใดๆ เข้ากับคอร์ของ WordPress ส่วนใหญ่เพราะ Backbone.js ไม่นานหลังจากถูกเพิ่มในคอร์ของ WordPress ได้รับความนิยมลดลงอย่างรวดเร็ว และนอกเหนือจากการเพิ่มพลังให้กับ Media Manager ยังมีฟีเจอร์ไม่มากนัก กับมัน แม้ว่า React จะเป็นไลบรารี JavaScript ที่ได้รับความนิยมมากที่สุดในขณะนี้ แต่ก็ไม่มีเหตุผลที่จะเชื่อได้ว่ามันจะเป็นอย่างนั้นเสมอ (ตามที่ jQuery สามารถพิสูจน์ได้) และ WordPress จะต้องเตรียมพร้อมเมื่อถึงวันนั้นในที่สุด (ซึ่งให้ความรวดเร็ว ของเทคโนโลยีที่อาจจะเกิดขึ้นเร็วกว่าที่คาดไว้)

วิธีที่ดีที่สุดในการหลีกเลี่ยงการล็อกไลบรารีใด ๆ คือการใช้มาตรฐานเว็บและโดยเฉพาะอย่างยิ่งในกรณีนี้คือการใช้บล็อกผ่านส่วนประกอบเว็บ ส่วนประกอบของเว็บเป็นส่วนประกอบที่มีการห่อหุ้มอย่างแน่นหนาซึ่งทำงานกับ API ของเบราว์เซอร์ ดังนั้นจึงไม่จำเป็นต้องใช้ไลบรารี JavaScript เพื่อทำงานด้วย อย่างไรก็ตาม สามารถใช้งานได้ผ่านเฟรมเวิร์ก JavaScript ฝั่งไคลเอ็นต์

แม้ว่า React จะไม่ได้ให้การผสานรวมกับส่วนประกอบเว็บอย่างราบรื่น แต่ในที่สุด (หรือค่อนข้างหวังว่า) ก็จะทำได้ ตามที่อธิบายในเอกสารของ React ส่วนประกอบเว็บและส่วนประกอบ React สามารถทำงานควบคู่ไปกับ:

“React และ Web Components ถูกสร้างขึ้นเพื่อแก้ปัญหาที่แตกต่างกัน Web Components ให้การห่อหุ้มที่แข็งแกร่งสำหรับส่วนประกอบที่นำกลับมาใช้ใหม่ได้ ในขณะที่ React มีไลบรารี่ที่เปิดเผยซึ่งช่วยให้ DOM ซิงค์กับข้อมูลของคุณ ทั้งสองเป้าหมายเสริมกัน ในฐานะนักพัฒนา คุณมีอิสระที่จะใช้ React ใน Web Components ของคุณ หรือใช้ Web Components ใน React หรือทั้งสองอย่าง”

ณ วันนี้ โอกาสที่สถานการณ์นี้จะเกิดขึ้นนั้นดูไม่สดใสนัก: ฉันยังไม่พบบทช่วยสอนสำหรับการสร้างบล็อคที่มีส่วนประกอบของเว็บ ฉันเชื่อว่าชุมชนควรมุ่งเน้นความพยายามไปที่สาเหตุนี้ โดยกระตุ้นให้นักพัฒนาเริ่มสร้างบล็อคโดยใช้คอมโพเนนต์ของเว็บ และยิ่งเร็วยิ่งดี เนื่องจากตอนนี้ Gutenberg บังคับให้เราเรียนรู้เทคโนโลยีใหม่ ๆ ในตอนนี้ เป็นโอกาสในการสร้างรากฐานที่แข็งแกร่งด้วยมาตรฐานเว็บตั้งแต่เริ่มต้น

การทำงานร่วมกันระหว่างไซต์ การทำให้เป็นเนื้อเดียวกันของไซต์

บล็อกเป็นเอนทิตีที่มีขนาดเล็กกว่าธีมหรือปลั๊กอิน ดังนั้นในที่สุดบล็อกจะสามารถเข้าถึงได้ด้วยตัวเอง และได้รับผ่านตลาดบล็อกที่สร้างขึ้นใหม่ เป็นไปได้มากว่าในตอนแรกจะมีการระเบิดของบล็อก Cambrian เนื่องจากผู้เล่นจำนวนมากในระบบนิเวศเร่งรีบที่จะเป็นคนแรกที่ทำการตลาดโซลูชันของพวกเขา ซึ่งนำไปสู่ระยะกลางและระยะยาวไปสู่การรวมกลุ่มที่ประสบความสำเร็จมากที่สุด

เมื่อฝุ่นจางลงแล้ว สองสามช่วงตึกจะโดดเด่นและกลายเป็นผู้ชนะ โดยได้ตลาดส่วนใหญ่ในหมวดหมู่เฉพาะของพวกเขา หาก/เมื่อสิ่งนั้นเกิดขึ้นจะเป็นสาเหตุของทั้งความกังวลและความปีติยินดี: ความกังวลเกี่ยวกับคลื่นลูกใหม่ของการทำให้เป็นเนื้อเดียวกันของเว็บที่เกิดขึ้น (เหมือนที่เกิดขึ้นกับ Bootstrap) เนื่องจากไซต์ที่ใช้ส่วนประกอบเดียวกันอาจมีลักษณะและความรู้สึกเหมือนกัน ความปีติยินดีเกี่ยวกับความสามารถในการทำงานร่วมกันที่เพิ่มขึ้นระหว่างไซต์ต่างๆ จากการพึ่งพาส่วนประกอบเดียวกันและ API เดียวกัน ซึ่งสามารถเปิดประตูสู่โอกาสใหม่ๆ

ฉันตื่นเต้นเป็นพิเศษเกี่ยวกับการขยายการทำงานร่วมกันระหว่างไซต์ต่างๆ เป็นพื้นที่ที่สามารถเลิกทำอาณาจักรเช่น Facebook ได้ในระยะยาว: แทนที่จะพึ่งพาเกตเวย์ผูกขาดในการแบ่งปันข้อมูล ไซต์ที่มีชุมชนต่างกันสามารถแบ่งปันข้อมูลระหว่างกันโดยตรงได้อย่างง่ายดาย นี่ไม่ใช่แนวคิดใหม่: การเคลื่อนไหวของ IndieWeb ได้ดำเนินการมาอย่างยาวนานเพื่อให้ทุกคนสามารถเป็นเจ้าของข้อมูลของตนเองบนเซิร์ฟเวอร์ของตนเองได้ โดยให้เว็บไซต์พูดคุยกันผ่านไมโครฟอร์แมต ตัวอย่างเช่น มาตรฐานเว็บ Webmention อนุญาตให้สองไซต์มีการสนทนา โดยที่ความคิดเห็นและการตอบกลับแต่ละรายการจะถูกเก็บไว้ในทั้งสองไซต์ และ Micro.blog เสนอ Twitter แปลก ๆ แต่อิงตามเว็บเปิดซึ่งโพสต์ บนไทม์ไลน์ของผู้ใช้จะรวบรวมจากฟีด RSS และ JSON จากไซต์ที่สมัครรับข้อมูล ความพยายามเหล่านี้ยอดเยี่ยม แต่ก็ยังส่งผลกระทบน้อยมาก เนื่องจากมีความชำนาญด้านเทคโนโลยีในระดับหนึ่งที่จำเป็นในการเป็นส่วนหนึ่ง สถาปัตยกรรมแบบอิงองค์ประกอบของ Gutenberg อาจสร้างผลกระทบในวงกว้างมากขึ้น: บล็อกยอดนิยมสามารถช่วยให้คะแนนของไซต์ WordPress สามารถพูดคุยกันได้ ในที่สุดก็อนุญาตให้มากถึง 30% ของไซต์ทั้งหมดบนเว็บเป็นส่วนหนึ่งของเครือข่ายที่กระจายอำนาจและเชื่อมต่อกันอย่างหลวม ๆ .

พื้นที่นี้จะต้องมีการทำงานมากมายก่อนที่จะทำงานได้ ฉันไม่คิดว่าปลายทาง REST เริ่มต้นเป็นอินเทอร์เฟซการสื่อสารที่ดีที่สุดเนื่องจากไม่ได้มีไว้สำหรับจุดประสงค์นี้ (กลุ่มคนจาก micro.blog ได้เสนอวิธีแก้ปัญหาที่ดีกว่าผ่านอินเทอร์เฟซ JSON ซึ่งเป็นไปตามข้อกำหนด RSS) นอกจากนี้ REST เองก็กำลังทำให้ GraphQL ล้าสมัย ดังนั้นฉันจะไม่ตั้งความหวังไว้สูงกับมันในระยะยาว ฉันยังมีส่วนร่วมในการหาวิธีที่ดีกว่า ซึ่งขณะนี้ฉันกำลังทำงานกับ API ประเภทอื่น ซึ่งสามารถดึงข้อมูลที่จำเป็นทั้งหมดได้ในคำขอเดียว และสนับสนุนการขยายผ่านสถาปัตยกรรมแบบส่วนประกอบ

ฉันยังคาดหวังว่าการผสานรวมกับบริการคลาวด์จะมีความโดดเด่นมากขึ้น เนื่องจากผู้ให้บริการสามารถปล่อยบล็อกของตนเองเพื่อโต้ตอบกับบริการของตนเองได้ เนื่องจากส่วนประกอบเป็นหน่วยแบบสแตนด์อโลน เพียงแค่ลากและวางบล็อกลงในหน้าเว็บก็ทำงานทั้งหมดจากมุมมองของผู้ใช้แล้ว ทำให้ง่ายต่อการสร้างเว็บไซต์ที่มีประสิทธิภาพโดยมีความรู้เพียงเล็กน้อยหรือไม่มีเลย ตัวอย่างเช่น ผู้ให้บริการพื้นที่จัดเก็บรูปภาพ เช่น Cloudinary สามารถปล่อยบล็อกที่ครอบตัดรูปภาพโดยอัตโนมัติตามวิวพอร์ตของอุปกรณ์ หรือขอรูปภาพเป็น WebP หากได้รับการสนับสนุน หรือกรณีการใช้งานอื่นๆ

โดยสรุป การรวมตัวของตลาดบล็อกอาจทำให้ลักษณะและความรู้สึกเป็นเนื้อเดียวกัน ซึ่งจะเป็นเหตุการณ์ที่น่าเสียใจและควรหลีกเลี่ยง และความสามารถอันทรงพลังเกี่ยวกับการทำงานร่วมกันและการแบ่งปันข้อมูลระหว่างไซต์และการผสานรวมกับบริการคลาวด์

บูรณาการกับไลบรารีรูปแบบ

ไลบรารีรูปแบบคือชุดขององค์ประกอบการออกแบบส่วนติดต่อผู้ใช้ ซึ่งแต่ละองค์ประกอบมักประกอบด้วยตัวอย่าง HTML, JS และ CSS บล็อกเป็นองค์ประกอบอิสระ ซึ่งมักประกอบด้วยบิตของ HTML, JS และ CSS ดังนั้นบล็อกจึงเหมาะสมอย่างยิ่งที่จะจัดทำเป็นเอกสาร/สร้างด้วยไลบรารีรูปแบบ การมีบล็อกในการจัดส่งไลบรารีรูปแบบของพวกเขาจะเป็นเรื่องที่ดีมาก เนื่องจากอาจทำให้ทีมไม่เริ่มใช้งานไลบรารีรูปแบบของไซต์เฉพาะที่ระดับไซต์เท่านั้น แต่เป็นการรวมกันและปรับแต่งไลบรารีรูปแบบขนาดเล็กจากบล็อกที่จำเป็นทั้งหมด

ฉันเชื่อว่าบางสิ่งที่คล้ายกับกระบวนการทำให้เพรียวลมสำหรับการผลิตแพ็คเกจ JavaScript แบบไม่มี bloatless ที่ฉันได้กล่าวถึงก่อนหน้านี้เกิดขึ้นในกรณีนี้ แต่เกี่ยวข้องกับ UI/UX/Documentation อาจเป็นทั้งความท้าทายและโอกาสสำหรับผู้มีส่วนร่วมของ Gutenberg ในการวางกระบวนการที่ทำให้นักพัฒนาบล็อกสร้างไลบรารีรูปแบบสำหรับบล็อกของตนได้ง่าย ซึ่งเมื่อรวมกันทั้งหมดแล้ว อาจส่งผลให้มีไลบรารีรูปแบบที่สอดคล้องกันสำหรับไซต์ นำมาใช้อย่างดี คุณลักษณะดังกล่าวสามารถลดต้นทุนของการสร้างไซต์จากมุมมองของเอกสาร/การบำรุงรักษา

WordPress จะเป็นอย่างไร?

Gutenberg จะทำให้เว็บไซต์น่าดึงดูดยิ่งขึ้นอย่างแน่นอน แม้ว่าจะต้องใช้ความเชี่ยวชาญในระดับที่จำเป็นซึ่งไม่ใช่ทุกคนจะรับมือได้ ในระยะยาว อาจส่งผลให้มีคุณภาพสูงขึ้น ปริมาณน้อยลง มาจากหลัก WordPress ของ "การเผยแพร่ประชาธิปไตย" นี่อาจเป็นปัญหาได้

ฉันกระตือรือร้นเกี่ยวกับ Gutenberg แต่เป็นแนวคิดของสถาปัตยกรรมแบบส่วนประกอบมากกว่าการใช้งานแบบ React ในแง่ทั่วไป ฉันเห็นด้วยกับสิ่งที่ Matt Mullenweg กล่าวระหว่าง WordCamp Europe 2018 เพื่อพิสูจน์ Gutenberg:

“รากฐานของ WordPress ที่ตอนนี้ให้บริการเราเป็นอย่างดีมาเป็นเวลา 15 ปี จะไม่คงอยู่ต่อไปอีก 15 ปี”

อย่างไรก็ตาม ฉันยังเชื่อว่า WordPress ในอนาคตสิบห้าปีอาจจบลงได้แตกต่างไปจากที่เรารู้จักในทุกวันนี้อย่างสิ้นเชิง ฉันสงสัยว่า WordPress จะเป็นตัวแก้ไขบนไคลเอนต์เป็นหลักหรือไม่ ความคิดริเริ่มในการรวม Gutenberg เข้ากับ Drupal โดยมีเป้าหมายเพื่อให้ Gutenberg กลายเป็นบรรณาธิการของเว็บเปิด จะทำให้ WordPress เป็นระบบปฏิบัติการ CMS ที่ไม่มีหัว ผ่านจุดปลาย REST นี่เป็นการพัฒนาที่ดีด้วยตัวมันเอง แต่จะทำให้ WordPress เป็นแบ็คเอนด์ที่ขาดไม่ได้: หากแพลตฟอร์มแบ็คเอนด์อื่นๆ มีคุณสมบัติที่ดีกว่า ไม่มีเหตุผลที่จะต้องยึดติดกับแบ็คเอนด์ของ WordPress อีกต่อไป ท้ายที่สุด Gutenberg ฝั่งไคลเอนต์จะสามารถทำงานกับพวกเขาได้ ในขณะที่ความเรียบง่ายในการสร้างเว็บไซต์ด้วย WordPress จะหายไป ทำให้ระดับสนามแข่งขันกับแพลตฟอร์มอื่น ๆ ทั้งหมด

โดยเฉพาะอย่างยิ่ง ฉันจะไม่แปลกใจเลยหากนักพัฒนารู้สึกว่าการรักษาฐานโค้ดสองอัน (อันหนึ่งเป็น JavaScript และอีกอันใน PHP) สำหรับการเรนเดอร์บล็อกแบบไดนามิกนั้นต้องเสียภาษีมากเกินไป และตัดสินใจที่จะเปลี่ยนไปใช้แพลตฟอร์มที่รองรับการเรนเดอร์ฝั่งเซิร์ฟเวอร์ isomorphic หากสถานการณ์นี้เกิดขึ้นจริง Matt จะตัดสินใจเปลี่ยนแบ็กเอนด์ของ WordPress เป็น Node.js หรือไม่

สาเหตุหลักมาจากปัญหานี้ที่ฉันกล้าพูดได้ว่า WordPress จาก 15 ปีจากนี้ไปอาจจะแตกต่างไปจากที่เป็นอยู่ทุกวันนี้ ใครจะรู้ว่าจะเกิดอะไรขึ้น?

บทสรุป

ด้วยการสร้างส่วนประกอบในหน่วยใหม่สำหรับการสร้างไซต์ การแนะนำ Gutenberg จะเปลี่ยนไปสู่ ​​WordPress และเช่นเดียวกับการเปลี่ยนกระบวนทัศน์ จะมีผู้ชนะและผู้แพ้ ผู้มีส่วนได้ส่วนเสียที่แตกต่างกันจะพิจารณาว่า Gutenberg มีการพัฒนาในเชิงบวกหรือเชิงลบขึ้นอยู่กับสถานการณ์ของตนเอง: ในขณะที่คุณภาพของเว็บไซต์จะเพิ่มขึ้น ราคาของการสร้างเว็บไซต์ดังกล่าวจากการว่าจ้างนักพัฒนาที่สามารถจัดการกับความซับซ้อนของเว็บไซต์ก็จะเพิ่มขึ้นเช่นกัน ทำให้ราคาไม่แพง และเป็นที่นิยมน้อย

นี่เป็นช่วงเวลาที่น่าตื่นเต้น แต่ก็เป็นช่วงเวลาสำคัญเช่นกัน จากนี้ไป WordPress อาจค่อยๆ กลายเป็นสิ่งที่แตกต่างไปจากที่เราคุ้นเคย และในที่สุดเราอาจต้องคิดว่า WordPress คืออะไร และเป็นตัวแทนของอะไร อีกครั้ง