การอภิปรายการเลือกเฟรมเวิร์ก JavaScript Core ของ WordPress ดำเนินต่อไปด้วยอินพุตจากผู้นำชุมชนโอเพ่นซอร์ส

แชนเนล #core-js Slack ของ WordPress ได้จัดการประชุมที่มีชีวิตชีวาและมีประสิทธิภาพเมื่อเช้านี้ นำโดย Andrew Duthie การอภิปรายเน้นไปที่การเปรียบเทียบเฟรมเวิร์กเฉพาะน้อยลง และบทบาทของเฟรมเวิร์กเพิ่มเติมในการสร้างอินเทอร์เฟซที่ขับเคลื่อนด้วย JavaScript สำหรับ WordPress Contributor ได้เข้าร่วมโดยนักพัฒนาหลักและผู้นำจากชุมชน React และ Vue, วิศวกร Chrome และผู้มีส่วนได้ส่วนเสียอื่นๆ จากนอกชุมชน WordPress

Duthie กล่าวว่า "การแชทนี้จะเน้นไปที่การระบุข้อกำหนดในการสร้างคุณลักษณะหลัก ทับซ้อนกับปลั๊กอินและผู้สร้างธีม และรูปแบบเพื่อลดการล็อกในกรอบงาน" Duthie กล่าว “ตามหลักการแล้วนี่เป็นระดับที่สูงกว่าการถกเถียงถึงข้อดีของเฟรมเวิร์กเฉพาะในสุญญากาศ และควรถูกมองว่าเป็นโอกาสในการทำงานร่วมกันระหว่างโครงการต่างๆ เพื่อกำหนดเส้นทางไปข้างหน้าสำหรับ WordPress ซึ่งจะให้ความยืดหยุ่นและความยืดหยุ่นในการปั่นป่วนในอนาคต”

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

Matias Ventura วิศวกรของ Gutenberg กล่าวว่า "ฉันไม่เห็นด้วยเล็กน้อยกับแนวคิดที่ว่าแกนหลักใดก็ตาม (ในกรณีนี้คือ Gutenberg) ใช้เพื่อเสริมความซับซ้อนในการสร้างแอป stateful บางส่วน “โดยทั่วไปแล้ว เฟรมเวิร์กของที่นี่จะเป็นสิ่งที่ WordPress เปิดเผยและ API”

ด้วยแนวทางที่ไม่เชื่อเรื่องพระเจ้าในกรอบงานเพื่อสร้าง Gutenblocks ไลบรารีที่แกนกลางตัดสินใจสร้างไม่จำเป็นต้องกลายเป็นมาตรฐานโดยพฤตินัยสำหรับนักพัฒนาปลั๊กอิน แต่หลายคนนอกทีม Gutenberg เชื่อว่ามันจะจบลงด้วยวิธีนั้นอย่างหลีกเลี่ยงไม่ได้ในทางปฏิบัติ มีทีมวิศวกรทั้งทีมที่รอการตัดสินใจนี้ซึ่งมุ่งมั่นที่จะนำกรอบงานใด ๆ ที่ WordPress วางเดิมพัน

“เพื่อให้มุมมองว่าการตัดสินใจของ WP เกี่ยวกับเฟรมเวิร์กส่งผลกระทบต่อนักพัฒนาดาวน์สตรีมอย่างไร ฉันเป็นนักพัฒนาที่มหาวิทยาลัยบอสตัน และแผนของเราคือมุ่งเน้นไปที่เฟรมเวิร์กที่ WP ตัดสินใจ แม้ว่า Gutenberg จะมี API ที่ไม่เชื่อเรื่องพระเจ้าอย่างสมบูรณ์” Adam Pieniazek กล่าว . “เราเป็นร้านค้า WP เป็นหลัก (การติดตั้ง WP ของไซต์ ~ 1,000 ไซต์มีอำนาจมากที่สุด/จำนวนมากของสถานะเว็บสาธารณะของเรา) และจบลงด้วยการสร้างการปรับแต่งจำนวนมากบน WP ที่มักจะต้องเจาะลึกลงไปในแกนกลางเพื่อดูว่าเกิดอะไรขึ้นในเบื้องหลัง . ฉันชอบ Vue มากกว่า React เป็นการส่วนตัว แต่ถ้า WP ตัดสินใจเกี่ยวกับ React BU จะเน้นที่การสร้างความเชี่ยวชาญใน React เมื่อเราต้องแอบดู/ดีบักนอกเหนือจาก API ไม่ได้หมายความว่าเราจะไม่ใช้ Vue ด้วย แต่จะไม่ใช่จุดสนใจหลักของเรา”

คำติชมของ Pieniazek สะท้อนถึง Carl Hancock ผู้ร่วมก่อตั้ง Gravity Forms ซึ่งกล่าวว่าทีมของเขาพร้อมที่จะนำสิ่งที่ WordPress เลือกมาใช้ในห้องสมุด

“ผู้คนจะลงเอยด้วยการใช้แกนกลางใดก็ตามที่ใช้เป็นส่วนใหญ่ แม้ว่าจะมีรุ้งและผีเสื้อที่บางคนอ้างว่าเกี่ยวข้องกับการสร้างเลเยอร์ที่เป็นนามธรรม เพื่อให้นักพัฒนาปลั๊กอิน/ธีมสามารถใช้สิ่งที่พวกเขาต้องการได้” แฮนค็อกกล่าวใน #core- ช่อง js เมื่อต้นสัปดาห์นี้

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

Paul Bakaus วิศวกรของ AMP กล่าวว่า "เนื่องจาก Gutenberg กำลังจะกลายเป็นแพลตฟอร์มสำหรับสร้าง การแยกระดับที่ดีที่สุดคือถ้าใช้เฟรมเวิร์กเพื่อสร้างแกนหลัก แต่ไม่ได้เปิดเผยเป็น API เพื่อบล็อกผู้สร้าง" “สิ่งนี้ทำให้มีทางเลือกในการเปลี่ยนรองพื้นเมื่อจำเป็น”

วิศวกรของ Gutenberg Riad Benguella สรุปแนวทางที่ทีมกำลังพูดถึง:

ฉันคิดว่าสิ่งที่เราพยายามสื่อสารนั้นมีลักษณะดังนี้:

– WordPress Core จะใช้ X framework นี้ภายใน
– หากต้องการใช้ เราว่าดี
– หากคุณต้องการใช้อย่างอื่น คุณสามารถทำได้ง่ายๆ เหมือนกับที่คุณใช้เฟรมเวิร์กที่เลือกของ Core

Benguella ยังกล่าวอีกว่าหนึ่งในเป้าหมายของ Gutenberg คือ "การกำหนดพื้นฐานสำหรับการขยาย UI ของ WordPress ในอนาคต" เมื่อจัดส่งแล้ว ทีมงานจะมุ่งไปที่ส่วนอื่นๆ ของ wp-admin และสร้างในลักษณะเดียวกัน

“หากทุกส่วนของ UI ของ WP สามารถขยายได้ผ่านอินเทอร์เฟซมาตรฐาน ไม่ว่าจะเป็น 'data down, events up' API หรือคาดหวัง WC ฉันคิดว่านี่จะแยกข้อกังวลของ 'เฟรมเวิร์กใดที่จะใช้สำหรับคอร์ได้อย่างชัดเจน ' เทียบกับ 'เฟรมเวิร์กใดที่จะใช้สำหรับการพัฒนาส่วนขยาย'” ผู้สร้าง Vue.js Evan You กล่าว

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

“ฉันไม่ค่อยรู้จัก WordPress ดีนัก ดังนั้นจึงยากสำหรับฉันที่จะพูดว่ามันเหมาะสมกับกรณีการใช้งานหรือไม่” Abramov กล่าว “โดยทั่วไปเราใช้ React สำหรับ UI ที่มีการโต้ตอบสูงและพบว่ามันปรับขนาดได้ดีกับขนาดแอพ ฉันยินดีที่จะตอบคำถามทางเทคนิคเกี่ยวกับเรื่องนี้ แต่ฉันคิดว่าโดยทั่วไปแล้ว คนทั่วไปมีความคิดเห็นที่หนักแน่นเกี่ยวกับเรื่อง เช่น การสร้างเทมเพลตกับการแสดงออก และฉันไม่รู้สึกว่าการบังคับให้ React กับทุกคนเป็นวิธีที่ดีที่สุด”

“ฉันก็รู้สึกเช่นเดียวกัน” Evan You กล่าว "การบังคับให้ใช้เฟรมเวิร์กเดียวกับทุกคน ไม่ว่าจะใช้เฟรมเวิร์กใด IMO ก็ไม่ใช่ความคิดที่ดี เพราะมันจะต้องทำให้กลุ่มนักพัฒนาซอฟต์แวร์ที่ไม่ได้อยู่ในเฟรมเวิร์กนั้นแปลกแยกออกไป และทำให้เกิดความเสี่ยงด้านเสถียรภาพในระยะยาวที่มากขึ้น"

อับรามอฟยังกล่าวอีกว่าผู้คน "ขมขื่นและแตกแยกอย่างมาก" อยู่แล้วเกี่ยวกับเรื่องของการเลือกกรอบงาน เขายังทวีตความรู้สึกที่คล้ายกันก่อนการประชุม

เมื่อฉันอ่านกระทู้สนทนา (เช่น เกี่ยวกับ WordPress) มีความรู้สึกว่าผู้คนมองว่าทุกทีมเป็นศัตรูกับผู้อื่น นั่นเป็นเท็จ

– แดน (@dan_abramov) 26 กันยายน 2017

คิดว่ามันเหมือนกับการดูแลสวน คุณสามารถออกไปเที่ยวกับเรา สวนอื่นก็สวยเหมือนกัน

– แดน (@dan_abramov) 26 กันยายน 2017

“ฉันเชื่อว่าเป็นสิ่งสำคัญ (และเป็นไปได้ในทางเทคนิค) ในการแยก 'เฟรมเวิร์กใดที่จะใช้สำหรับคอร์' และ 'เฟรมเวิร์กที่ชุมชนผู้พัฒนาใช้สำหรับส่วนขยาย'” Evan You กล่าว

“ใช่ ฉันคิดว่ามีเป้าหมายที่นี่ที่จะไม่แสดงความคิดเห็นสำหรับสิ่งที่เราเปิดเผยต่อผู้เขียนปลั๊กอิน ตราบใดที่ API/อินเทอร์เฟซที่เราเปิดเผยนั้นมีความยืดหยุ่นเพียงพอ (และง่าย) ในการสร้าง UI และการโต้ตอบที่พวกเขาจำเป็นต้องนำไปใช้ แอนดรูว์ ดูธี กล่าว

หัวข้อการสนับสนุนการทำงานร่วมกันของเว็บส่วนประกอบสำหรับ Gutenblocks ก็เป็นส่วนหนึ่งของการอภิปรายในระหว่างการประชุม

“แม้ว่าจะมีประสิทธิภาพน้อยกว่าเฟรมเวิร์กจริงส่วนใหญ่ ณ จุดนี้ แต่ก็มีแนวโน้มที่จะกลายเป็นมาตรฐาน W3C เพื่อให้แน่ใจว่าพวกเขาจะคงอยู่และพัฒนา” เฟลิกซ์อาร์นทซ์กล่าว “บวกกับเมื่อรองรับเบราว์เซอร์อย่างเต็มรูปแบบแล้ว การใช้งานจริงก็จะน้อยลงตามกรอบงานจริงที่สร้างขึ้นบน”

Justin Fagnani ตัวแทนของ Polymer.js กล่าวว่าเขาไม่เห็นด้วยว่าพวกเขา “มีประสิทธิภาพน้อยกว่า” และตั้งข้อสังเกตว่าส่วนประกอบเว็บเป็นมาตรฐาน W3C แล้ว

“ฉันคิดว่า WP อยู่ในตำแหน่งที่ไม่เหมือนใครเพื่อช่วยผลักดันการสนับสนุนส่วนประกอบเว็บในทุกที่” ผู้พัฒนา EventEspresso หลัก Darren Ethier กล่าว “เฟรมเวิร์กเกือบทั้งหมดมีความสามารถในการทำงานกับข้อมูลจำเพาะของส่วนประกอบเว็บได้ในขณะนี้ มันเป็นเพียงเรื่องของการดำเนินการที่เหมาะสม”

ผู้เข้าร่วมหลายคนอ้างอิง custom-elements-everywhere.com ซึ่งเป็นไซต์ที่แสดงความคืบหน้าของ JS frameworks ที่เป็นที่นิยมในการสื่อสารองค์ประกอบที่กำหนดเองในลักษณะที่ส่งเสริมการทำงานร่วมกัน Matias Ventura ถามผู้พัฒนาหลักของ React และ Vue ว่าองค์ประกอบของเว็บ (และอนาคต) เหมาะสมกับแต่ละเฟรมเวิร์กอย่างไรในขณะนั้น

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

"ในระดับสูง ฉันคิดว่าเฟรมเวิร์กอย่าง React/Vue ให้สิ่งที่ไม่ได้กล่าวถึงจริงๆ ในส่วนประกอบของเว็บ: การอัปเดต DOM ที่มีประสิทธิภาพและเปิดเผยซึ่งตอบสนองต่อการเปลี่ยนแปลงสถานะ" Evan You กล่าว “นี่คือเหตุผลว่าทำไมโพลีเมอร์ถึงอยู่ด้านบนของห้องสุขา ฉันรับรู้ถึงคุณค่าของ WC เสมอว่าเป็นอินเทอร์เฟซการทำงานร่วมกัน”

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