Diskusi Pemilihan Kerangka Inti JavaScript WordPress Berlanjut dengan Masukan dari Pemimpin Komunitas Sumber Terbuka

Saluran Slack #core-js WordPress menyelenggarakan pertemuan yang hidup dan produktif pagi ini yang dipimpin oleh Andrew Duthie. Diskusi kurang berfokus pada perbandingan kerangka kerja tertentu dan lebih pada peran kerangka kerja dalam membangun antarmuka berbasis JavaScript untuk WordPress. Kontributor bergabung dengan pengembang inti dan pemimpin dari komunitas React dan Vue, insinyur Chrome, dan pihak berkepentingan lainnya dari luar komunitas WordPress.

“Obrolan ini sebagian besar akan fokus pada mengidentifikasi persyaratan dalam membangun fitur inti, tumpang tindih dengan plugin dan pembuat tema, dan pola untuk mengurangi penguncian kerangka kerja,” kata Duthie. “Idealnya ini adalah tingkat yang lebih tinggi daripada sekadar memperdebatkan manfaat kerangka kerja tertentu dalam ruang hampa, dan harus dilihat sebagai peluang untuk berkolaborasi antar proyek guna menetapkan jalan ke depan bagi WordPress yang akan memberikan fleksibilitas dan ketahanan untuk churn di masa mendatang.”

Duthie memulai dengan menanyakan peran apa yang harus dimainkan oleh kerangka kerja dalam alur kerja pengembang WordPress dan juga meminta kontributor kerangka kerja untuk menawarkan perspektif mereka tentang rekomendasi untuk antarmuka yang dapat diperpanjang. Pertanyaan ini memberi peserta kesempatan untuk mempertimbangkan topik-topik seperti dukungan untuk komponen web, interoperabilitas blok kerangka-agnostik untuk Gutenberg, dan bagaimana hal ini dapat memengaruhi ekosistem plugin WordPress.

“Saya sedikit tidak setuju dengan gagasan bahwa inti apa pun (dalam hal ini Gutenberg) yang digunakan untuk memperkuat beberapa kerumitan membangun aplikasi stateful akan menjadi standar de facto untuk pengembangan plugin,” kata insinyur Gutenberg Matias Ventura. “Kerangka kerja sebenarnya di sini, secara umum, akan menjadi apa yang diekspos WordPress dan API.”

Dengan pendekatan kerangka-agnostik untuk membangun Gutenblocks, perpustakaan yang diputuskan untuk dibangun oleh inti tidak harus menjadi standar de facto untuk pengembang plugin tetapi banyak di luar tim Gutenberg percaya bahwa itu pasti akan berakhir seperti itu dalam praktiknya. Ada seluruh tim insinyur yang menunggu keputusan ini yang berkomitmen untuk mengadopsi kerangka kerja apa pun yang dipertaruhkan WordPress.

“Untuk memberikan beberapa perspektif tentang bagaimana keputusan WP pada kerangka kerja berdampak pada pengembang hilir, saya seorang pengembang di Universitas Boston dan rencana kami adalah untuk fokus pada kerangka kerja mana pun yang diputuskan WP, bahkan jika Gutenberg memiliki API yang sepenuhnya agnostik,” kata Adam Pieniazek . “Kami pada dasarnya adalah toko WP (~ 1.000 situs WP menginstal kekuatan sebagian besar / banyak kehadiran web publik kami) dan akhirnya membuat penyesuaian besar di atas WP yang sering kali membutuhkan menyelam ke inti untuk melihat apa yang sebenarnya terjadi di latar belakang . Saya lebih menyukai Vue daripada React secara pribadi, tetapi jika WP memutuskan React, BU akan fokus membangun keahlian dalam React ketika kita perlu mengintip/men-debug di luar API. Itu tidak berarti kami tidak akan menggunakan Vue tetapi itu tidak akan menjadi fokus utama kami.”

Umpan balik Pieniazek menggemakan co-founder Gravity Forms Carl Hancock, yang mengatakan timnya siap untuk mengadopsi perpustakaan apa pun yang dipilih WordPress.

“Orang-orang pada akhirnya akan mengadopsi penggunaan inti apa pun untuk sebagian besar meskipun ada pelangi dan kupu-kupu yang diklaim beberapa orang terkait dengan pembuatan lapisan abstraksi sehingga pengembang plugin/tema dapat menggunakan apa pun yang mereka inginkan,” kata Hancock di #core- js saluran awal minggu ini.

Banyak peserta dari luar komunitas WordPress tampaknya setuju dengan pendekatan kerangka-agnostik dan tidak ada yang ingin memaksakan kerangka kerja tunggal pada semua pengembang yang bekerja dengan WordPress. Kekhawatiran yang tersisa adalah bagaimana ini bekerja secara praktis dan apakah itu menempatkan pengembang pada posisi yang membingungkan dalam menggunakan kerangka kerja di atas kerangka kerja.

“Karena Gutenberg sendiri akan menjadi platform untuk membangun, tingkat pemisahan terbaik adalah jika kerangka digunakan untuk membangun inti, tetapi tidak diekspos sebagai API untuk memblokir pembuat,” kata insinyur AMP Paul Bakaus. “Ini memberi seseorang pilihan untuk mengganti fondasi yang mendasarinya kapan pun diperlukan.”

Insinyur Gutenberg, Riad Benguella, merangkum pendekatan yang telah didiskusikan oleh tim:

Saya pikir apa yang kami coba komunikasikan adalah seperti:

– WordPress Core akan menggunakan framework X ini secara internal
- Jika Anda ingin menggunakannya, kami pikir itu bagus
– Jika Anda ingin menggunakan sesuatu yang lain, Anda dapat dengan mudah menggunakan kerangka kerja Core yang dipilih

Benguella juga mengatakan bahwa salah satu tujuan Gutenberg adalah “untuk menetapkan dasar bagaimana kami memperluas UI WordPress di masa depan.” Setelah dikirimkan, tim kemungkinan akan mengarahkan pandangannya ke bagian lain dari wp-admin dan membangunnya dengan cara yang sama.

“Jika semua bagian dari UI WP dapat diperluas melalui antarmuka standar, apakah itu API sederhana 'data down, event up', atau mengharapkan WC, saya pikir ini akan memisahkan kekhawatiran tentang 'kerangka kerja apa yang digunakan untuk inti. ' vs. 'kerangka kerja apa yang digunakan untuk pengembangan ekstensi,'” kata pembuat Vue.js, Evan You.

Ketika ditanya pendapatnya tentang React menjadi framework utama untuk WordPress, pengelola React Dan Abromov ragu-ragu untuk mengadvokasi WordPress untuk mengadopsi library tersebut. Tanggapannya menggarisbawahi perlunya memiliki pendekatan kerangka-agnostik untuk memperluas Gutenberg dan perbaikan antarmuka WP di masa depan.

“Saya tidak begitu tahu WordPress dengan baik, jadi sulit bagi saya untuk mengatakan apakah itu cocok untuk kasus penggunaan atau tidak,” kata Abramov. “Umumnya kami menggunakan React untuk UI yang sangat interaktif dan ternyata skalanya sesuai dengan ukuran aplikasi. Saya juga senang menjawab pertanyaan teknis tentang hal itu. Tetapi saya pikir secara umum orang memiliki pendapat yang kuat tentang, misalnya, templating vs ekspresif, dan saya tidak merasa bahwa memaksakan Bereaksi pada semua orang adalah cara terbaik.”

“Saya juga merasakan hal yang sama,” kata Evan You. “Memaksakan satu kerangka kerja pada semua orang, terlepas dari yang mana, adalah IMO bukan ide yang baik karena itu pasti akan mengasingkan kelompok pengembang yang tidak masuk ke dalam kerangka kerja itu, dan menimbulkan risiko stabilitas jangka panjang yang lebih besar.”

Abramov juga mengatakan bahwa orang-orang sudah “sangat pahit dan memecah belah” tentang masalah pemilihan kerangka kerja. Dia juga mentweet sentimen serupa sebelum pertemuan.

Ketika saya membaca utas diskusi (misalnya tentang WordPress) ada perasaan bahwa orang menganggap setiap tim bermusuhan dengan orang lain. Itu salah.

— Dan (@dan_abramov) 26 September 2017

Anggap saja seperti merawat taman. Anda dipersilakan untuk nongkrong di tempat kami. Taman lain juga bagus

— Dan (@dan_abramov) 26 September 2017

“Saya percaya itu penting (dan layak secara teknis) untuk memisahkan 'kerangka kerja mana yang digunakan untuk inti' dan 'kerangka kerja mana yang digunakan pengembang komunitas untuk ekstensi,'” kata Evan You.

“Ya, saya pikir ada tujuan di sini untuk tidak memikirkan apa yang kami ekspos ke pembuat plugin, selama API/antarmuka yang kami ekspos cukup fleksibel (dan mudah) untuk membangun UI dan interaksi yang perlu mereka implementasikan, ” kata Andrew Duthie.

Topik mendukung interoperabilitas komponen web untuk Gutenblocks juga menjadi bagian dari diskusi selama pertemuan.

“Meskipun kurang kuat daripada kebanyakan kerangka kerja sebenarnya pada saat ini, mereka cenderung menjadi standar W3C, memastikan bahwa mereka akan bertahan dan berkembang,” kata Felix Arntz. “Ditambah lagi setelah dukungan browser sepenuhnya ada, ada lebih sedikit fungsionalitas untuk diterapkan oleh kerangka kerja aktual yang dibangun di atas.”

Perwakilan Polymer.js Justin Fagnani mengatakan dia tidak setuju bahwa mereka "kurang kuat" dan mencatat bahwa komponen web sudah menjadi standar W3C.

“Saya pikir WP juga diposisikan secara unik untuk membantu mendorong dukungan untuk komponen web secara asli di mana-mana,” kata dev inti EventEspresso Darren Ethier. “Hampir semua kerangka kerja memiliki kemampuan untuk bekerja dengan spesifikasi komponen web sekarang. Ini hanya masalah implementasi yang tepat.”

Beberapa peserta merujuk custom-elements-everywhere.com, sebuah situs yang menampilkan kemajuan kerangka kerja JS populer dalam mengomunikasikan Elemen Kustom dengan cara yang mempromosikan interoperabilitas. Matias Ventura bertanya kepada pengembang inti React dan Vue bagaimana komponen web (dan masa depan mereka) cocok dengan setiap kerangka kerja saat ini.

“Di React, kami memiliki beberapa dukungan komponen web tetapi belum menjadikannya prioritas besar karena kasus penggunaan tampak ramping di masa lalu, terutama karena menambahkan Komponen Web tidak masuk akal dalam aplikasi pihak pertama di mana Anda mengontrol seluruh tumpukan – tetapi kami memiliki beberapa dukungan untuk mereka dan saya senang untuk menghibur menambahkan lebih banyak, baik sekarang atau di masa depan, ”kata Sophie Alpert.

“Pada tingkat tinggi saya pikir kerangka kerja seperti React/Vue menyediakan apa yang tidak benar-benar dibahas dalam komponen web: pembaruan DOM yang efisien dan deklaratif yang bereaksi terhadap perubahan status,” kata Evan You. “Ini juga mengapa Polymer ada di atas WC. Saya selalu mengakui nilai WC sebagai antarmuka interop.”

Secara keseluruhan, peserta rapat bersikap hormat, kolaboratif, dan bersemangat untuk menyumbangkan keahlian mereka untuk membantu kontributor WordPress menemukan jalan terbaik ke depan dalam proses pemilihan kerangka kerja. Diskusi akan berlanjut pada pertemuan minggu depan dan kemungkinan dalam komentar dari posting Make/Core yang akan datang yang merangkum pertemuan tersebut.