Gutenberg: Memilih Kerangka JavaScript untuk Gutenberg (~ WordPress)

Pilihan saya adalah dengan VueJS

Saya memilih VueJS

Vue memiliki komunitas yang hebat dan harus menjadi pilihan ke depan.

JS sudut

Saya akan memilih VueJS. Seperti yang diuraikan di atas, ini ramah pemula dan berhasil digunakan dengan Laravel. Itu membuatnya menjadi pilihan yang sempurna.

Saya juga akan memilih Vue JS

Harap dicatat bahwa hanya berteriak "Saya lebih suka Vue" atau "Saya ingin XY" tidak benar-benar membantu pengambilan keputusan di sini. Jika Anda ingin memberikan suara, saya sarankan untuk menggunakan reaksi emoji atau semacamnya daripada mengacaukan utas yang mungkin dapat bertindak sebagai tempat untuk mendokumentasikan temuan saat mengevaluasi kerangka kerja yang berbeda.

Saya akan pergi dengan Vue. Lebih mudah untuk belajar dan beradaptasi. Ditambah itu kurang kontroversial dari Preact.

Untuk masalah "Key person dependency" yang muncul dari waktu ke waktu, bukankah itu yang dimaksud dengan setiap plugin fitur WordPress atau teknologi yang tidak dikenal? Koop membangun penanganan media lama, Weston melakukan banyak pekerjaan Penyesuai, Matías dan beberapa lainnya mengerjakan Gutenberg, hampir setiap perubahan besar pada WordPress yang telah terjadi dalam beberapa tahun terakhir memiliki sekelompok kecil orang yang mengerjakannya atau memahaminya.

Saya bisa melihat ini dengan cara yang salah tetapi "ketergantungan orang kunci" untuk pilihan apa pun tampaknya seperti ikan haring. Dengan adopsi, ketergantungan orang kunci dihilangkan seluruhnya. WordPress pernah menjadi proyek ketergantungan orang-orang penting (Mike dan Matt) juga. Saya pikir itu argumen yang lemah untuk menghindari adopsi.

Sekali lagi, saya bisa saja berpikir tentang ini sepenuhnya salah, tetapi ini adalah benang merah pemikiran yang saya lihat bermunculan dari waktu ke waktu dan tidak memahami pentingnya yang tampaknya tinggi.

Untuk menambah komentar @swissspidy , menunjukkan daripada memberi tahu adalah sesuatu yang juga dapat membantu. Jika orang-orang sangat menginginkan penggantinya, peragakan perubahan tersebut dan seperti apa tampilan kode di sebuah cabang (seperti yang dilakukan # 2734 untuk Preact). Tidak peduli apa keputusan akhirnya, Gutenberg akan lebih baik dalam eksplorasi daripada mengacaukan utas diskusi.

Saya akan memilih VueJS! Sejauh ini, cara termudah untuk diadaptasi oleh komunitas.

Saya pikir komponen web (tanpa Polymer, tetapi dengan lit-html atau serupa jika DOM virtual diperlukan) harus dipertimbangkan dengan serius. Menggunakan platform dan standar jauh lebih baik daripada pustaka atau kerangka kerja apa pun! Membuat struktur komponen yang kuat dan aman di masa depan, yang secara alami dapat dioperasikan dengan semua kerangka kerja. (Vue, Angular, React - ke tingkat yang berbeda saat ini: https://custom-elements-everywhere.com/)

• https://blog.revillweb.com/why-web-components-are-so-important-66ad0bd4807a
• https://medium.com/@velmu/go -long-on-web-components-b1e0689f64e4

Saya senang membantu proyek ini untuk mencoba Vue atau komponen web jika diperlukan.

Lihat juga PR # 2463 untuk Gutenberg _ "Interoperabilitas blok agnostik kerangka kerja (Vanilla, Vue)" _

Saya sarankan untuk condong ke Vue.js karena beberapa alasan.

1. Rekam jejak yang terbukti dalam kerangka PHP Laravel.
2. Tampaknya mudah diambil dan diadopsi sehingga lebih banyak orang dapat berkontribusi.
3. Jika kita menjauh dari React, mari kita jadikan perubahan yang bersih dan pasti darinya (Menggunakan Preact sepertinya kita menempel padanya (React) dalam arti tertentu).

Hanya pendapat saya tetapi sepertinya pilihan yang lebih baik dan banyak orang lain tampaknya menyukai Vue serta setidaknya itu sesuatu yang perlu dipertimbangkan.

Vue tampaknya memiliki momentum yang lebih besar dan dukungan komunitas yang lebih baik daripada Preact. Ini memecahkan lebih banyak masalah (karena dilengkapi dengan manajemen negara) dan memiliki kurva belajar yang lebih lembut. Dokumentasinya _excellent_.

Perhatian saya dengan Preact adalah bahwa React terlalu seperti React untuk merasa aman secara hukum (paten React mungkin mencakup Preact), dan terlalu berbeda dengan React menjadi port sederhana (ada perbedaan _enough_ untuk merusak pustaka pembantu, plugin dll).

Vue sepanjang jalan sayang !!

• [x] [Gitlab] (https://about.gitlab.com/2016/10/20/why-we-chose-vue/)
• [x] [HN] (https://news.ycombinator.com/item?id=14410190)
• [x] [PixelJets] (http://pixeljets.com/blog/why-we-chose-vuejs-over-react/)

Github Stars -> Sini
Akan sangat senang untuk WordPress dev jika Vue.js 🖖

Vue telah mengembangkan komunitas yang hebat dari waktu ke waktu ditambah pembaruan / peningkatan berkala ke kerangka kerja.

PS. bergabunglah dengan https://chat.vuejs.org untuk pengalaman komunitas yang luar biasa .. beberapa pengembang yang sangat keren di sana :)

@jbreckmckye Saya tidak bermaksud untuk menggagalkan percakapan, tetapi apakah Anda memahami tentang apa klausul paten itu? Ini tentang melindungi facebook dari tuntutan hukum paten dari perusahaan lain. Misalnya, perusahaan saya membuat lemari es pintar dan kami menggunakan react di UI. Katakanlah kita memiliki paten untuk ini, dan kemudian FB mulai melanggar paten itu ... jika kita menuntut kita tidak bisa lagi menggunakan react.

Ini tidak ada hubungannya dengan paten dalam bereaksi (yang saya bahkan tidak yakin facebook memiliki ... jika tidak preact, vue dan siapa pun dengan kerangka kerja yang sama akan dituntut sekarang)

Sebagai anggota inti Vue.js, saya ingin membahas masalah faktor bus. Kami tahu hal ini saat ini merupakan poin yang sangat banyak diangkat, kami sekarang sedang mengambil langkah-langkah untuk mengatasi beberapa masalah.

1) Akun org Vue.js untuk npm, sehingga kami dapat menerbitkan sebagai tim lebih mudah
2) Secara internal mengelola detail agar semuanya tetap berjalan (situs web, dll)
3) Memulai kolektif terbuka, untuk menarik kontributor dan mendukung komunitas yang berkembang. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) Ekosistem Vue telah berkembang pesat, dan semakin banyak kontribusi penyimpanan inti datang dari komunitas itu sendiri. https://www.youtube.com/watch?v=993X1kiisFE
5) Saat melihat repositori resmi Vue, Anda dapat melihat bahwa sebenarnya banyak dari mereka sekarang sangat dipelihara oleh anggota tim inti lainnya lebih dari Evan

Secara keseluruhan Vue.js berkembang pesat dan 'Faktor Bus' telah berkurang secara signifikan. Seperti yang dicatat oleh

Sepertinya ada banyak penggemar VueJS di sini. Adakah yang benar-benar memigrasi basis kode besar dari React ke Vue? Seperti apa jalur migrasi itu?

Dari apa yang saya lihat, Preact sepertinya merupakan pilihan yang jauh lebih pragmatis mengingat itu adalah API yang kompatibel dengan React. Sedangkan migrasi ke Vue akan membutuhkan penulisan ulang yang jauh lebih ekstensif.

@patrickgalbraith Sebenarnya itulah alasan yang salah untuk mempertimbangkan Preact. Ini harus dinilai berdasarkan manfaatnya dan bukan karena lebih mudah untuk bermigrasi ke sana. Saya dapat melihat masalah berikut dengan Preact

• Komunitas yang lebih kecil dibandingkan dengan VueJS
• Code Smells - Transisi ke pustaka yang sangat mirip dapat memaksa praktik buruk (karena alasan yang jelas itu menjadi jalur yang lebih cepat)
• Tetap menggunakan Preact itu seperti tetap menggunakan React (baca di utas)

Saya hanya menggunakan Preact secara terbatas, jadi, inilah yang saya pikirkan.

@ blake-newman Terima kasih telah mampir dan membereskan masalah itu. 💯

Ini harus dinilai berdasarkan manfaatnya dan bukan karena lebih mudah untuk bermigrasi ke sana.

Ya. Ini adalah keputusan jangka panjang.

@patrickgalbraith jika seluruh proyek selesai, maka saya akan menganggap itu argumen yang adil. Karena ini akan menjadi bagian migrasi untuk menghindari masalah perizinan.

Karena proyek ini masih dalam tahap awal, seperti @ahmadawais , ini bukan masalah.

Vue, React, dan Preact juga memiliki paradigma yang sangat mirip. Anda dapat dengan mudah beralih di antara keduanya, akan ada perbedaan.

Ada juga, meski mungkin tidak sepenuhnya praktis dalam hal ini alat yang dapat membantu perdamaian migrasi. https://github.com/SmallComfort/react-vue

Meskipun ini tidak membandingkan alat yang sama, artikel ini mengangkat poin bagus untuk dipertimbangkan. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman apakah ini benar-benar hanya tahap awal meskipun mengingat sudah lebih dari 6 bulan dalam pengembangan? Juga perlu diingat Calypso juga berusia lebih dari dua tahun.

Bagaimanapun saya yakin ini tidak akan menjadi masalah karena mengingat apa yang Anda katakan bahwa mudah untuk beralih antara React dan Vue. Saya menantikan untuk melihat permintaan tarik untuk itu.

Stensil juga terlihat menjanjikan.

https://github.com/ionic-team/stencil-starter

Pendapat saya adalah bahwa 2 poin ini menjadi alasan kuat untuk Vue:

• Ramah pemula dan ..
• Dukungan komunitas dalam jumlah besar

Keduanya, menurut saya, adalah 2 pilar inti dari proyek WordPress.

Saya mungkin sendirian tetapi saya telah mengamati Evan's Patreon dengan cukup cermat selama enam bulan terakhir ini, dan terbaca bahwa jika dia tidak bisa mendapatkan dana melalui itu, dia perlu mengambil lebih banyak pekerjaan.

Ini adalah risiko nyata ketika sebuah proyek memiliki pendanaan rendah DAN pada dasarnya ditulis oleh satu orang (sejak <enam bulan yang lalu). Faktanya, nomor Patreon-nya turun belakangan ini. Jika orang utama mengatakan dia mungkin tidak dapat mengerjakannya jika keuangan tidak sesuai, maka keuangan adalah risiko yang sangat nyata. Pilihan kerangka kerja proyek jangka panjang yang besar yang bergantung pada apakah satu pengembang (hebat) yang dapat membayar sewa SF adalah masalah besar.

Tentu saja Vue dapat didukung dengan murah hati oleh perusahaan lain tetapi sulit untuk mengetahuinya.

Adopsi komunitas juga tidak menjamin ketahanan framework, guys. Jika Anda belum menyadarinya, kerangka kerja 'mati' sepanjang waktu.

Yang mengatakan, saya terkesan bahwa seorang anggota tim inti Vue muncul untuk benar-benar mengatasi masalah kontributor tunggal / faktor bus, bahkan dengan nama, dan memberikan beberapa alasan bahwa masalah dev tunggal mungkin kurang menjadi masalah. Tapi itu adalah masalah nyata di masa lalu.

saya memilih Vue

• api sederhana / Anda dapat mempelajari hal-hal paling dasar dalam waktu kurang dari seminggu
• implementasi fluks sederhana melalui vuex
• hasil cepat: P
• komunitas yang berkembang
• MIT

Vue lainnya, untuk semua alasan yang disebutkan di atas. Saya minta maaf kepada siapa pun dengan pemberitahuan email diaktifkan!

@ michaelbdavidson7 , Vue akhirnya akan mendapatkan masukan dari Evan dan kampanye Patreon adalah mendukungnya untuk melakukan lebih banyak pekerjaan Vue yang hebat. Dia tidak mendapatkan cukup melalui Patreon dan mengambil pekerjaan lain menurut saya tidak membahayakan Vue. Seperti yang disarankan oleh @ blake-newman (kontributor inti Vue) (dan Evan sendiri beberapa bulan yang lalu), Vue tidak lagi bergantung pada satu orang saja. Sebanyak WordPress tidak bergantung pada satu orang. Kami memiliki Matt, ya, tetapi WordPress dapat melanjutkan dalam beberapa inkarnasi tanpa Matt (maaf Matt;)). Hal yang sama berlaku untuk Vue (maaf Evan;)).
@ahmadawais yang menurut saya juga kurang akurat tentang "ketergantungan orang kunci".

Jika tujuan ini tercapai, saya dapat menghabiskan lebih sedikit waktu untuk memikirkan saluran monetisasi pribadi (misalnya mengambil kontrak dukungan / konsultasi) dan sebaliknya bekerja lebih banyak pada konten yang menguntungkan seluruh komunitas Vue ...

^ Sasaran itu tidak tercapai dan bahkan belum tercapai. Dengan asumsi dia bersungguh-sungguh dengan apa yang dia katakan, dia mungkin masih memikirkan tentang kontrak, dan jika itu berubah maka itu harus dianggap sebagai perkembangan yang sangat baru. Itu masih di atas sana sampai sekarang. Jika orang kunci mengontrak untuk membayar sewa, ada risiko dia mungkin tidak terus mengerjakan kerangka kerja, dan jika itu berubah maka itu berubah baru-baru ini.

Kalian semua hanya meneriakkan kerangka kerja dengan nama tidak belajar apa-apa selama beberapa tahun terakhir lol.

@ michaelbdavidson7 Tujuannya tercapai untuk mendukung Evan mengerjakannya secara penuh waktu. Tujuan tambahannya ada untuk membantu mendukungnya lebih jauh dan sebagian untuk komunitas. Dengan demikian lahirlah kampanye kolektif terbuka yang bertujuan semata-mata untuk mendukung masyarakat.

Saya juga akan menunjukkan bahwa kampanye Patreon bukan satu-satunya sumber pendapatan melalui kontribusi, sayangnya Patreon tidak cocok untuk setiap perusahaan yang disponsori. Jadi beberapa kontribusi dibayar dan ditagih secara terpisah.

Alasan turunnya jumlah tersebut, karena salah satu sponsornya berasal dari China, dan ada batasan jumlah uang yang bisa dikeluarkan dari China dalam setahun. Ini hanya sementara dan mudah-mudahan akan kembali mendukung.

Saluran pendapatan lain yang didapat Evan melalui lokakarya, tidak hanya membantu masyarakat tetapi juga untuk dia. Dengan cara ini dia bisa mendapatkan eksposur langsung untuk mendukung pembelajaran bagaimana perpustakaan akan dan digunakan. Jadi sebenarnya tidak seburuk kelihatannya.

Vue berkelanjutan, dan saya tidak berbicara atas nama Evan, tapi saya yakin dia sangat senang dengan situasi keuangan saat ini.

Satu hal yang sangat saya hargai tentang React adalah dokumentasi aksesibilitasnya . Saya pikir ini adalah sesuatu yang harus diperhatikan dan dipertimbangkan ketika memikirkan kerangka kerja baru. Ada prinsip aksesibilitas yang disebutkan di sini yang berlaku untuk aplikasi web apa pun yang ditulis secara defensif, tetapi memiliki beberapa dokumentasi khusus kerangka kerja dapat membantu.

Vue.js memiliki masalah terbuka untuk aksesibilitas . Sekilas tentang Preact dan saya tidak melihat banyak; apakah aman untuk mengasumsikan bahwa dokumentasi dari React berlaku?

Pada akhirnya, akan sangat bagus untuk memiliki kerangka kerja yang membuat pengujian terprogram untuk a11y sederhana dan otomatis sehingga kami dapat menghilangkan sebagian besar kesalahan dan peringatan a11y.

Jika Anda ingin transisi yang mudah hanya karena lisensi maka salah satu opsi yang dapat Anda pertimbangkan adalah InfernoJS. https://github.com/infernojs/inferno menawarkan API yang hampir sama dengan footprint yang lebih kecil dan waktu proses yang lebih cepat. Lisensi MIT-nya. Saya salah satu pengelola neraka dan saya dapat membantu transisi.

@Havunen terima kasih sudah mampir. Saya melihat Inferno beberapa hari yang lalu, belum mencobanya. Tampak menjanjikan!

Untuk konteksnya, penulis Inferno dipekerjakan oleh Facebook

Saya memilih markoJS http://markojs.com/

Gutenberg menggunakan beberapa fitur React 16 baru yaitu Portal & mungkin Fragmen , yang tidak didukung oleh Inferno dan Preact sehingga dapat dipertimbangkan ketika berbicara tentang libs mirip React jika penggunaan fitur-fitur ini penting untuk gutenberg.

Saya akan menyarankan DIO 8 terutama karena ini adalah hal yang paling dekat dengan React 16 pada saat ini dalam hal API.

Yang mengatakan, mungkin percobaan keingintahuan yang baik untuk mengatur Gutenberg aliasing libs mirip React yang disebutkan dan melihat apakah mereka berfungsi tanpa perubahan / masalah apa pun untuk siapa pun yang mau.

Saya tidak yakin apakah mereka persis sama, tetapi untuk portal, ada vue-portal yang dikembangkan oleh @LinusBorg , salah satu anggota tim inti vue :)

@youknowriad Saya dipekerjakan oleh Facebook. @Havunen dan tim di belakang Inferno melakukan pekerjaan dengan baik tanpa saya. Pekerjaan yang mereka lakukan di Inferno luar biasa dan proyek ini layak untuk dicoba di Inferno jika Anda mendapat kesempatan :)

Saya salah satu penulis Marko.js dan ingin memasukkan Marko.js ke dalam ring untuk dipertimbangkan. Sejumlah anggota komunitas kami telah menghubungi kami dan mengarahkan kami ke masalah GitHub ini. Marko.js memiliki lisensi MIT ramah sumber terbuka dan digunakan untuk membangun eBay.com dan memiliki komunitas yang kuat dan berkembang. Ini membawa sejumlah ide bagus dari React dan Vue, tetapi kami berusaha keras untuk membuat segalanya lebih sederhana dan lebih cepat (melalui optimasi waktu kompilasi) dan kami menghapus boilerplate kapan pun kami bisa. Saya hanya ingin menyoroti beberapa fitur di bawah ini:

Komponen UI

Model komponen Marko sangat mirip secara konseptual dengan React (input, state, event binding, event daur hidup, rendering DOM virtual, DOM diffing / patching, dll.). Transisi di Calypso tidak membutuhkan banyak overhead kognitif. Marko juga mendukung komponen UI file tunggal. Berikut tampilan komponen Marko UI:

class {
  onInput(input) {
    this.state = { 
      count: input.count || 0 
    };
  }
  increment() {
    this.state.count++;
  }
}

style {
  .count {
    color:#09c;
  }
}

<div.count>${state.count}</div>
<button on-click('increment')>
  Click me!
</button>

Sintaksis

Marko tidak menggunakan JSX, tetapi superset dari HTML yang mendukung ekspresi JS. Ini sangat mirip dengan HTML, tetapi tidak sepenuhnya terbatas pada HTML seperti Vue. Ini memberikan sintaks yang lebih baik untuk hal-hal seperti loop dan kondisional dan membuatnya lebih jelas di mana ekspresi digunakan vs string HTML standar. Kami merasa template Marko.js sangat mudah dibaca dan dipelihara (Marko juga mendukung sintaks yang ringkas dan berbasis indentasi).

Rendering sisi server

Saya tidak tahu betapa pentingnya untuk WordPress, tetapi Marko juga mendukung rendering sisi server berkinerja tinggi di bawah Node.js dengan dukungan untuk rendering asinkron dan streaming.

Bacaan lebih lanjut:

• Marko vs Bereaksi
• Adu Rendering Sisi Server dengan Marko, Preact, Rax, React, dan Vue
• Mengapa Marko cepat?
• 10 Fitur Marko yang Luar Biasa
• Meetup: Membangun UI - perbandingan antara React, Vue, dan Marko (dari pencipta Marko) - Video | Slide

Saya memilih Marko !! 🙂

Jika ada orang dari tim WordPress (@ahmadawais? @M? @Swissspidy?) Ingin mengobrol singkat untuk menjawab pertanyaan apa pun tentang Marko, kami, tim Marko, dengan senang hati akan melakukannya. : call_me_hand: 😸

@Saya mengomentari ini di blog @m , tetapi ingin mempostingnya di sini dalam bentuk yang lebih umum:

Saya merekomendasikan ekosistem Ember termasuk Ember dan Glimmer.js.
Untuk komponen web yang lebih kecil seperti penurunan editor dan perilaku konten lainnya, Glimmer memberikan pengalaman hebat dan membuat penurunan komponen web yang dapat berjalan di luar kerangka kerja.

Untuk proyek yang lebih besar seperti Guttenberg dan Calypso di mana perutean, pengelolaan status yang kompleks, kontrol akses, pengelolaan konten, dan lainnya berperan penting: Ember menyediakan perangkat dan ekosistem terbaik
Dengan sekumpulan besar kontributor: Ember's set pattern, addons, dan build system membantu menjaga kinerja dan pemeliharaan aplikasi sesuai skala aplikasi.
Ember Engines dan in-repo addons membantu menjaga bagian opsional dari aplikasi tetap modular dan dapat dipasang untuk pengguna akhir.

Ember banyak digunakan oleh sistem manajemen konten lain dan upaya tersebut dapat dibangun, dipelajari, dan dibagikan.
Seperti yang disebutkan dalam komentar sebelumnya di blog @m , Ghost menggunakan Ember untuk admin dan editor mereka, tetapi Ember juga digunakan dengan Drupal headless, Cardstack , dan perusahaan konten seperti Conde Nast , Bustle , dan banyak lagi.
Artinya, fitur umum seperti daftar tag, editor berbasis komponen (khususnya editor Mobiledoc ), dan lainnya tersedia sebagai bagian dari ekosistem Ember Addon .

Dari komunitas dan pengalaman pengembang, Ember paling cocok dengan ekosistem Wordpress (sebagai pengembang yang bekerja di Wordpress selama lebih dari 5 tahun).
Ember memiliki banyak praktik terbaik baik yang terpasang, didokumentasikan dengan baik, atau tersedia melalui addons; ini mengurangi pertanyaan "apakah ini akan berfungsi dengan aplikasi saya" dan membantu mengurangi kemungkinan bug keamanan atau kinerja dengan lebih baik.
Ember dibangun di atas abstraksi yang dapat disesuaikan yang berarti bahwa kompleksitas dapat diabstraksikan dari pengembang akhir dan kode yang sulit dapat dibatasi dalam cakupannya untuk membuat penyesuaian mudah dan menyenangkan.
Add-on Ember sangat cocok dengan plugin dan tema Wordpress karena ditemukan secara otomatis dan memiliki konfigurasi default di luar kotak, tetapi dapat lebih disesuaikan untuk memenuhi kebutuhan pengguna akhir.
Ada alat kurasi untuk Ember Addons yang disebut Ember Observer untuk membantu menemukan add-on yang paling populer, paling terawat, dan paling stabil.

Calypso dan Guttenberg adalah proyek besar dan ambisius dengan kebutuhan yang matang. Komunitas Ember memiliki solusi yang matang untuk aksesibilitas, internasionalisasi, dan persyaratan lain dari aplikasi web modern.

Saya adalah bagian dari Tim Pembelajaran Ember.js dan bekerja sama dengan kontributor inti, saya ingin berbicara atau memulai percakapan dengan anggota Tim Ember lainnya tentang bagaimana Ember dan Glimmer dapat memenuhi kebutuhan Anda.

Saya perhatikan bahwa ada penyebutan tentang portal React dan ingin menambahkan 2 ¢ lagi bahwa Ember memiliki addon yang terawat dengan baik yang disebut Ember Wormhole untuk menyediakan fungsionalitas ini dan banyak addons dibangun di atasnya untuk menyediakan fitur seperti dialog, perubahan kepala dokumen , dan lainnya.

Saya akan memilih Marko untuk dukungan rendering asinkron asli dan kinerja sisi server yang cepat. !!!

@ patrick-steele-idem & @mlrawlings - terima kasih sudah mampir. Saya tahu pasti bahwa MarkoJS sangat kuat. Meskipun saya belum memiliki kesempatan untuk menggunakannya dalam sebuah proyek, saya memimpin sebuah proyek di mana para pengembang menggunakan MarkoJS untuk mesin rendering animasinya yang cepat. Itu sangat berbeda dan mengesankan.

Saya akan menggali lebih dalam.

Saya telah bekerja dengan Ember.js baik di organisasi perusahaan yang sangat besar di mana aplikasi berjalan di dalam aplikasi lain dan pada startup yang sangat kecil dengan aplikasi mandiri kecil. Pendapat dan konvensi yang kuat dari Ember.js telah membantu menjaga basis kode yang produktif dan dapat dipelihara saat tim dan aplikasi tumbuh. Ini tidak hanya memungkinkan kemampuan untuk berbagi kode (melalui mesin atau addons) di seluruh proyek tetapi juga memungkinkan pengembang yang telah mempelajari konvensi menjadi produktif dan berkontribusi pada hampir semua aplikasi Ember.

Manfaat terbesar Ember adalah stabilitasnya tanpa stagnasi. Tanpa harus mengubah template kami, kami mendapatkan keuntungan performa yang sangat besar saat versi baru Ember dirilis yang telah memperbaiki mesin rendering di bawah kami. Tingkat abstraksi tampaknya tepat untuk aplikasi web modern yang kaya yang mungkin tumbuh dan perlu ditingkatkan ke masa depan yang jauh.

Ketika perubahan diperlukan, migrasi adalah perhatian utama dan panduan penghentian membantu setiap langkah (yang terbaru menggunakan JavaScript AST / CST mengubah untuk secara otomatis meningkatkan aplikasi).

Aplikasi web populer lainnya yang menggunakan Ember yang tidak disebutkan oleh @rtablada termasuk Twitch.tv , dasbor Heroku , Travis CI , dan Discourse .

@SaladFork terima kasih atas pembaruannya, saya mulai dengan menyebut sebagian besar perusahaan di arena manajemen konten.

Beberapa contoh Aplikasi Ember open source skala besar meliputi:

• Travis CI
• Hospital Run - Sistem EMR (Electronic Medical Record) yang dibuat untuk penggunaan offline terutama dalam konektivitas rendah di Afrika
• Hantu

Saya tidak yakin seberapa banyak dia bisa menjelaskan secara mendetail, tetapi saya mengirim ping ke

Saya akan memilih Marko untuk kinerjanya, fleksibilitas dan sintaksnya yang sangat jelas dan mudah dimengerti!

1 untuk Marko, juga. Setelah melakukan pekerjaan front-end dengan baik sebelum saya mulai kehilangan rambut dan beruban (seperti, dulu sekali), itu telah menjadi kerangka kerja / perpustakaan front-end yang saya cari selama bertahun-tahun ini. Itu alasan utama mengapa saya suka bekerja di eBay dengan @ patrick-steele-idem & @mlrawlings juga.

Marko JS memiliki suara saya. Sangat diremehkan mengingat kemudahan penggunaan dan kinerja.

Saya suka marko-widget bersama dengan marko yang efisien. kerangka kerja yang luar biasa dan ramping. Ini jauh lebih cepat daripada kerangka kerja lainnya. Tolok ukur ada di sini

Saya memilih MarkoJS, kami telah menjadi toko setang selama bertahun-tahun.

Ketika kami membuat langkah strategis untuk masuk ke layanan mikro dan mengaktifkan arsitektur berbasis komponen untuk platform kami, kami sedang mencari kerangka kerja yang tepat untuk memiliki keseimbangan antara rendering sisi server dan rendering klien. Kami adalah platform yang telah diklasifikasikan di 6 pasar berbeda termasuk pasar negara berkembang seperti Afrika Selatan dan Meksiko, di mana data menjadi perhatian besar dan kami perlu memiliki situs yang benar-benar memenuhi persyaratan penelusuran pengguna pada perangkat yang berusia beberapa tahun dan juga menggunakan lebih sedikit data. Selain itu, pengguna akan menavigasi situs bolak-balik sampai dia menemukan item yang ingin dia beli, yang berarti kita perlu melakukan rendering server yang sangat cepat saat pengguna menavigasi.

Setelah mempertimbangkan dengan cermat, kami memilih MarkoJS dengan fakta yang didukungnya:

1. Rendering server cepat dengan kinerja server yang baik
2. Mendorong byte pertama secepat mungkin
3. Kemampuan untuk membangun komponen kecil dan merendernya secara asinkron ketika data sudah siap
4. Kemampuan untuk membangun arsitektur komponen plug and play
5. Maksimalkan rendering klien dengan arsitektur yang sama atau lebih baik dari React / Vue.
6. Pengujian berbasis komponen yang dapat digunakan tidak hanya untuk menguji rendering, tetapi juga status komponen

(Kisah sukses dari eBay Classifieds)

1 untuk Angular (BUKAN AngularJS).

Angular CLI sejauh ini adalah yang terbaik dari semua kerangka kerja, dan dengan rencana migrasi yang tersedia untuk migrasi tanpa batas antar versi, itu akan sangat cocok.

Plus Angular sangat diadopsi dengan baik di ranah perusahaan, di mana WordPress dapat menggunakan cinta jika WordPress akan terus tumbuh sebagai platform untuk konsultan dan freelancer, dan tidak lagi menjadi perlombaan ke bawah.

Itu memiliki komunitas pengembang yang kuat dari semua tingkatan. Tim inti selalu luar biasa untuk berbicara apakah mereka bekerja untuk Google atau tidak. WordPress sebagian besar (untuk sebagian besar pengembang tingkat tinggi) komunitas tempat mereka terlibat, jadi saya akan mengatakan bahwa dari segi komunitas, Angular sangat cocok

Saya baru-baru ini berbicara di Vue di Server-Rendered Environments ( slide di sini ), dan telah bekerja dengan Vue di lingkungan .NET selama beberapa bulan terakhir, saya yakin tidak ada pilihan lain untuk bekerja di lingkungan seperti itu. Anda mendapatkan kombinasi yang sangat bagus untuk dapat mengkomponen apa yang perlu ditarik ke dalam JS untuk interaktivitas yang berat sambil memungkinkan back-end untuk terus mengontrol sebagian besar situs.

Yang berarti itu cukup sempurna untuk membangun di atas apa yang dimiliki WordPress sekarang. Pustaka JS lain yang dirender server kemungkinan besar akan membutuhkan node. Vue tidak; Anda dapat mendaftarkan komponen seperti <gutenberg-editor> dan membuat WordPress benar-benar mengirimkan <gutenberg-editor> dalam HTML. Vue dapat menggunakan HTML yang dikirim oleh WordPress untuk bootstrap halaman. Ini seperti komponen web dalam hal itu, dan tidak memerlukan teknologi BE lain untuk mendapatkan rendering server.

Itulah salah satu alasan kerangka kerja seperti Laravel memilihnya sebagai default: sangat mudah untuk diintegrasikan ke dalam back-end non-Node. Saya pikir WordPress harus mengadopsinya untuk alasan yang sama.

Saya memilih Vuejs .
Begitu pula halnya dengan komentarnya

CTO saya memperkenalkan Vuejs ke tim - pendatang baru di Front-end, dan mereka dengan cepat memahaminya, sekarang mereka senang dengan Vuejs. Tim saya menggunakan WordPress di banyak proyek.
Saat ini, kami menggunakan Vuejs dan Custom Element untuk membuat front-end untuk proyek yang menggunakan WordPress di backend. Ini bekerja dengan sangat lancar.

Seperti yang dikatakan @blake-newman dan Evan, Vuejs tidak lagi bergantung pada satu key person lagi, sehingga bisa dikatakan CONS yang disebutkan @ahmadawais sudah tidak ada lagi.

MARKO bekerja dengan baik di aplikasi web kami. Rendering progresif bekerja seperti pesona.

Saya tidak dapat mengatakan apa-apa tentang Preact atau MarkoJS (sangat dirujuk pada komentar) tetapi saya dapat berbicara untuk Vue saat saya memperkenalkannya kepada tim kami (terutama bekerja pada php + jQuery saat itu) setahun yang lalu dan secara bertahap mengubah pemahaman mereka tentang javascript, keluar dari pikiran jQuery.

Saya pikir ini akan menjadi pilihan yang baik tidak hanya untuk Gutenberg tetapi untuk tujuan jangka panjang WordPress, bertransisi ke platform yang lebih berorientasi API dengan lebih banyak javascript pada antarmuka. Kurva pembelajaran yang lebih mudah dan keakraban akan mendorong pengembang WP lain untuk ikut serta.

Saya melihat bagaimana VueJS berkembang pesat di komunitas Laravel dan hampir menjadi pilihan defacto bagi sebagian besar orang, saya yakin akan seperti itu juga di komunitas WordPress.

Backbone.js

/ s

Saya ingin memberikan dukungan saya di belakang MarkoJS.

Dua tahun lalu saya memindahkan infrastruktur perusahaan saya dari ExpressJS dan Jade (sekarang PUG) ke Marko JS. Perusahaan saya ingin membuat komponen yang rumit dan dapat digunakan kembali di seluruh ekosistem kami. Pengembang menginginkan kecepatan dan kegunaan kembali. Desainer menginginkan penurunan beban desain. Kami belum melihat ke belakang sejak itu.

Kami sekarang memiliki beberapa situs web yang berhadapan dengan klien yang ditulis dalam Marko dan seluruh sistem CMS juga.

Akhirnya, saya memilih MarkoJS sebagai berikut:

• Rendering server cepat bahkan dengan kerangka kerja seperti Koa dan atau ExpressJS
• Menangani perenderan data halaman secara asinkron
• Kemampuan untuk membangun komponen plug and play untuk ekosistem yang lebih besar
• Performa lebih baik dari React / Vue
• Sintaks template yang sangat mudah

Saya juga ingin menunjukkan bahwa tim MarkoJS benar-benar luar biasa. @ patrick-steele-idem dan @mlrawlings selalu siap untuk melembagakan ide-ide baru, memperbaiki masalah, dan membantu individu.

👍 untuk MarkoJS

Preact adalah pustaka yang kompatibel dengan React-API yang berarti Preact mendapat manfaat langsung dari ekosistem React dan sejumlah besar paket / komponen OSS yang tersedia. Sistem eko ​​Vue jauh lebih kecil dibandingkan. Dokumentasi untuk paket / komponen Vue pihak ketiga dalam bahasa Cina.

Tolong, tidak ada lagi "Saya memilih XYZ", mereka tidak melakukan apa pun untuk ditambahkan ke percakapan selain mengirim balasan yang tidak perlu kepada orang-orang yang berlangganan edisi ini

🔥 Sudut

• PRO: Pesaing terbesar React
  Untuk banyak orang. pertanyaannya sering kali "Angular or React?" / "Bereaksi atau Sudut?". Komunitas Angular bisa dibilang yang terbesar di antara alternatif React, dan berkembang pesat.

• PRO: Banyak sumber belajar
  Selain dokumen dan panduan API resmi, Angular mungkin memiliki ekosistem terbesar untuk materi pendidikan, entri blog, buku, dan banyak kursus video, baik gratis maupun komersial di setiap platform pembelajaran utama, ditambah Google GDE yang mengajarkannya dalam lokakarya dan konferensi.

• PRO: Terintegrasi dengan baik dengan Redux
  Baik secara langsung, atau melalui RxJS yang diberdayakan Ngrx (didukung oleh anggota tim Angular)

• PRO: Dukungan perkakas terbaik di kelasnya

  • CLI memiliki lebih banyak fitur daripada yang lain

  • Dukungan editor yang sangat baik di VS Code terutama dengan layanan bahasa

  • Ditulis untuk TypeScript, memberikan pengalaman TypeScript terbaik

• PRO: Fitur kaya, beropini, dan diatur secara default
  Pemisahan logis melalui Angular Modules (NgModule), serta fitur standar untuk formulir, panggilan HTTP, perutean, dll memudahkan pengembang lain untuk membaca kode dan berkontribusi padanya

• PRO: Integrasi terbaik dengan RxJS
  Berguna untuk banyak aliran API, dan banyak aliran peristiwa di satu halaman secara umum

• PRO: Sistem DI (Dependency Injection) bawaan
  Berguna untuk membuat poin ekstensibilitas dan bahkan mungkin sistem plugin, terutama bila digabungkan dengan RxJS

• PRO: Kutu banyak kotak lain yang dicakup perpustakaan lain

  • Perpustakaan UI dengan lisensi permisif
    Ada PrimeNg, Angular Material 2, ngx-bootstrap, dan masih banyak lagi ...

  • Pemuatan lambat
    Dukungan bawaan untuk rute pemuatan lambat, dan juga mendukung modul pemuatan lambat secara manual

  • CSS khusus komponen
    Memastikan CSS hanya dibatasi ke komponen, dimuat hanya saat komponen dimuat, dan memiliki kait untuk CSS global

  • Rendering sisi server
    Sudah bekerja dengan Node dan ASP .NET Core, dan mendapatkan fokus yang lebih baik saat ini

  • Menguji
    Angular menyediakan unit-test-framework agnostic test helpers yang membuat pengujian unit menjadi sangat mudah. Mereka menghasilkan tes secara default dari CLI menggunakan Jasmine, yang dapat dengan mudah dialihkan ke Jest. Mereka juga menyediakan Busur derajat pembungkus Selenium opsional untuk membuat pengujian E2E lebih mudah (meskipun Anda tidak benar-benar membutuhkannya, saya menggunakan Selenium .NET untuk aplikasi Angular saya, tidak ada yang spesifik untuk Angular, tetapi mereka mencoba membuatnya lebih mudah).

  • Dukungan seluler / PWA
    Google adalah pendukung terbesar PWA, dan dukungannya sudah muncul di CLI Angular dengan Service Workers dan Universal (dukungan sisi server), dan Ionic (dukungan Cordova), dan NativeScript (aplikasi Native)

• PRO: Fokus pada dukungan browser
  Dengan halaman polyfill khusus di dokumen, dan menyisipkan polyfill (berkomentar) secara default di CLI, Angular membuat Anda tetap mengetahui polyfill yang tepat yang Anda perlukan untuk mengatakan IE <= 11, jadi Anda tidak perlu memuat polyfill yang jauh lebih besar ditetapkan tanpa alasan. Itu karena mereka peduli dengan dukungan browser.

• PRO: Dukungan perusahaan besar
  Angular adalah salah satu dari sedikit perpustakaan yang dibahas di sini (satu-satunya?) Yang didukung oleh perusahaan besar.
  Dengan mendukung di sini, bukan hanya perusahaan yang menggunakannya dalam beberapa proyek dan berkontribusi kembali pada ekosistem, tetapi menjadi pengelola resmi yang membayar pengembang dan penulis teknis untuk bekerja penuh waktu, dan berinvestasi pada pemimpin komunitas (GDE dan DevRel dalam kasus ini). dari Google).
  Ini PRO bukan CON karena dilengkapi dengan lisensi MIT tanpa klausul tambahan, tidak ada catatan pencabutan, atau apa pun yang dapat membingungkan atau menakutkan bagi sebagian orang.

Saya telah mengimplementasikan Vuejs untuk beberapa proyek seperti plugin, REST API. Saya harus mengatakan itu mudah dipelajari, memiliki banyak fitur, komunitas besar dan ekosistemnya juga bagus.

Saat ini, Vuejs berkembang pesat. Ini akan menjadi pilihan bijak jika Vuejs diintegrasikan ke dalam kode WordPress.

@cyberwani @ephilip @evoratec dan lainnya.

@ntwb telah membalas komentar berikut:

Tolong, tidak ada lagi "Saya memilih XYZ", mereka tidak melakukan apa pun untuk ditambahkan ke percakapan selain mengirim balasan yang tidak perlu kepada orang-orang yang berlangganan edisi ini

Jadi, tolong berhenti membuat komentar yang tidak berguna. Untuk menunjukkan dukungan Anda, Anda dapat menggunakan emoji github untuk menyukai komentar yang mendukung perpustakaan Anda.

Vue.

Ngomong-ngomong, ada Alibaba di belakang Vue sekarang, serta proyek Weex Apache yang mengaktifkan Vue api di perangkat seluler.

Saya benar-benar akan memberi sedikit kesederhanaan di sini, terlalu banyak penggemar pria tanpa argumen yang jelas

Ini adalah peringatan terakhir, langkah selanjutnya adalah kita mulai menghapus komentar ...

Saya sendiri, saya belum pernah menggunakan Marko, Preact, atau Vue.js, sejujurnya saya tidak akrab dengan salah satu dari mereka, saya ingin mendengar dan membaca apa yang dikatakan Komunitas WordPress tentang kerangka kerja ini, masing-masing, manfaat teknis masing-masing, ekosistem di sekitarnya masing-masing, peralatan bangunan, dan yang terakhir namun tidak kalah pentingnya adalah orang dan komunitas di balik proyek ini. 😄

Saya tidak ingin membaca "Pilihan saya adalah untuk XYZ", jika Anda ingin menambahkan suara, gulir ke atas dan tambahkan emoji _thumbs up_ reaksi ke kerangka pilihan Anda yang telah disebutkan di atas. 👍

Tidak butuh waktu lama untuk dua komentar baru muncul sejak komentar saya sebelumnya 😞

Untuk itu ... Jika komentar Anda ditambahkan setelah https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 dan semua yang Anda katakan adalah _ "Saya memilih XYZ" _ atau SMS ke sana karena komentar Anda memiliki peluang yang sangat tinggi untuk dihapus , komentar serupa di masa mendatang juga akan dihapus .

Jika Anda kembali ke masalah ini dan bertanya-tanya mengapa komentar Anda dihapus, inilah alasannya

@ahmadawais Saya punya beberapa komentar.

Migrasi Gutenberg dari React ke ...?

Mengenai:

@patrickgalbraith Sebenarnya itulah alasan yang salah untuk mempertimbangkan Preact. Ini harus dinilai berdasarkan manfaatnya dan bukan karena lebih mudah untuk bermigrasi ke sana. Saya dapat melihat masalah berikut dengan Preact

• Komunitas yang lebih kecil dibandingkan dengan VueJS
• Code Smells - Transisi ke pustaka yang sangat mirip dapat memaksa praktik buruk (karena alasan yang jelas itu menjadi jalur yang lebih cepat)
• Tetap menggunakan Preact itu seperti tetap menggunakan React (baca di utas)

Saya pikir ketika Anda memiliki proyek dengan jumlah baris kode yang tidak sepele, Anda harus sangat berhati-hati. Insinyur suka menulis ulang sesuatu, mempelajari bahasa dan kerangka kerja baru, dan berpikir mereka akan melakukan pekerjaan yang lebih baik jika mereka dapat menulis ulang kode itu ... Joel berbicara tentang bahaya penulisan ulang dengan cukup fasih sejak lama .
Menggunakan Preact akan menghemat banyak waktu. Anda mungkin meremehkan waktu yang dibutuhkan untuk pindah ke kerangka kerja yang benar-benar baru. Saya tidak yakin mengapa Anda menulis "Itu sebenarnya alasan yang salah untuk mempertimbangkan Preact". Sebagai seorang insinyur, biaya dan waktu untuk memasarkan adalah yang tertinggi dalam daftar kriteria yang saya gunakan untuk mengevaluasi dan memilih solusi.
Jika masalahnya benar-benar pada paten Facebook, Preact menyelesaikannya dengan meminimalkan biaya. Preact lebih berkinerja daripada React dan bahkan Vue: footprint yang lebih kecil dan rendering runtime yang lebih cepat. Periksa juga tulisan Addy Osmani di atasnya .

Saya tidak yakin bagaimana Anda mengevaluasi ukuran komunitas Preact. Jika kita berbicara tentang ekosistem dan komponen yang tersedia, menggunakan Preact memungkinkan Anda menggunakan sebagian besar komponen bersumber terbuka React. Jadi untuk masalah praktis, Anda memiliki orang-orang yang meskipun mereka tidak secara eksplisit mengerjakan Preact, mereka masih menghasilkan kode yang dapat Anda manfaatkan. Anda masih dapat menganggap ekosistem React sebagai bagian dari ekosistem Preact.

Mengapa Vue masih menjadi pilihan favorit Anda?

Saya merasa bahwa poin ke-3 di sini "Tetap menggunakan Preact seperti tetap menggunakan React" mungkin adalah alasan utama Anda ragu-ragu untuk memilih Preact. Apakah aku salah? Apa yang salah dengan React selain patennya?

Melihat gambaran besarnya

Saya membaca bahwa apa pun yang Anda pilih untuk Gutenberg juga akan digunakan untuk Calypso.
Gutenberg hanya menggunakan React di frontend. Saat Anda melihat rendering sisi server, situasinya menjadi lebih kompleks tetapi Preact tampaknya masih merupakan opsi migrasi yang lebih mudah.

Saya pikir Anda perlu melihat kriteria Anda. Jika Anda secara serius mempertimbangkan untuk menulis ulang dan mempertahankan rendering isomorfik itu penting, MarkoJS tampaknya berada di atas daftar kandidat.

Jika saya memulai dari awal dan ingin mengabaikan ekosistem React, MarkoJS tidak perlu dipikirkan lagi.

Saya melihat penampilan dan MarkoJS sepertinya tidak memiliki saingan . 40x lebih cepat dari React, 10x lebih cepat dari Vue dan 6x lebih cepat dari Preact itu gila. Dalam buku saya, peningkatan 30% tidak relevan tetapi bila Anda memiliki peningkatan lebih dari 10x, Anda perlu memperhatikan dengan serius.
Ketika Anda memiliki kehadiran sukses yang sederhana dan Anda dapat menggunakan 10 server alih-alih 100, atau 2 alih-alih 20, itu membuat perbedaan besar.

Pengungkapan penuh Saya tidak memiliki keterikatan emosional dengan Preact atau MarkoJS. Saya hanya berpikir bahwa mereka lebih masuk akal daripada alternatif dari seorang calon teknisi.

Semoga berhasil dengan keputusan Anda 😃

@ChrisCinelli itu nomor ssr ...

Saya dari dunia Drupal (kami sedang memperhatikan masalah ini: D) jadi saya tidak memiliki andil dalam hal ini. Tapi membaca komentar, jelas bahwa ada sekitar 5 kerangka "teratas" di sini dan semua orang menyukai yang mereka pilih sehingga mereka akan memberikan alat peraga.

Aspek kecepatan tidak relevan hari ini, sungguh. Dua faktor yang harus dipertimbangkan adalah a) apakah Anda benar-benar ingin menulis ulang semuanya dan b) bagaimana transisi untuk developer React akan seperti dan bagaimana mempelajari fw pemenang untuk developer baru.

Ada lapisan preact-compat, inferno-compat ... untuk transisi yang mudah tetapi kinerjanya akan terganggu. Di sisi lain itu akan membuat transisi anggun seiring waktu, tidak semuanya harus ditulis ulang sekaligus. Dari bisnis POV, ini tidak sulit. Dari POV komunitas dan masa depan tidak ada bedanya.

Sekarang DX adalah tempat semuanya berada. Siapapun yang berpengalaman dalam fws reaktif seharusnya tidak memiliki masalah dalam transisi ke fw baru hanya karena konsepnya sama, hanya sintaksnya yang berbeda. Tapi pemula, itulah yang penting. Betapa sulit / mudahnya menjadi produktif di fw baru. Seberapa sulit / mudah untuk membaca dan memahami kode yang ada. Dan ini hanya terletak pada a) dokumentasi yang baik dan b) komunitas (forum, SO, chatroom, blog ..).

Saya tidak akan mengatakan FW mana yang saya pilih karena seperti yang saya katakan, saya bukan orang WP. Tapi saya ingin memberikan 2c saya untuk membuat kepala Anda tetap tenang saat harus mengambil keputusan besar yang akan memengaruhi ribuan developer di seluruh dunia.

@ntwb: Saya tidak punya komentar saya dihapus tapi saya pikir menghapus komentar, bahkan mereka anak laki-laki penggemar, sebagai semacam sensor.

Mengapa:

Jika komentar Anda ditambahkan setelah # 2733 (komentar) dan semua yang Anda katakan adalah "Saya memilih XYZ" atau teks yang menyatakan bahwa komentar Anda memiliki peluang sangat tinggi untuk dihapus, komentar serupa di

Saya melihat banyak komentar fan boy di atas itu. Mengapa mereka tetap tinggal?
Sepertinya standar ganda.

Angular, itu pilihan yang jelas. Saya pikir Roy dan Meligy membuat poin fantastis dan mendukung mereka 100%. WordPress bergerak ke ranah Enterprise tidak hanya dalam penggunaan, tetapi juga dalam hal metodologi pengembangannya.

Saya akan menautkan sumber yang menyenangkan: https://vuejs.org/v2/guide/comparison.html dan khususnya: "... kompleksitas Angular sebagian besar disebabkan oleh tujuan desainnya yang hanya menargetkan yang besar dan kompleks aplikasi...". Pernyataan sederhana itu tepat sasaran. WordPress adalah, dan arah masa depannya akan terus menjadi, aplikasi kompleks yang tangguh.

@ChrisCinelli Hanya karena saat itulah kami meminta orang untuk tidak mengatakan "Saya memilih xyz", saya mengerti dari mana asal Anda, tetapi saya pikir menghapus komentar itu akan menjadi bentuk yang buruk, saya tidak menyukai kenyataan bahwa saya harus melakukannya hapus salah satu dari mereka

Saya tidak membawa ini lebih awal karena saya tidak ingin menyerang kerangka kerja yang tidak saya rekomendasikan (telah merekomendasikan Angular di atas), tetapi hanya untuk kelengkapan, ada sesuatu yang perlu diselesaikan dengan Preact dan pustaka serupa React lainnya . Saya akan menaruhnya di sini, dan terserah WordPress untuk memutuskan apakah itu masalah.

Berikut ini adalah kutipan dari postingan yang ditulis oleh Pengacara Hak Paten / HKI atas lisensi React, (highlight tebal disalin dari sumbernya):

Saya mendapat banyak jawaban "Baiklah, mari kita semua gunakan [kerangka kerja alternatif di sini]." Tunggu sebentar. Jika paten Facebook mencakup React (diffing, componentization, dll), paten tersebut kemungkinan mencakup Preact / Vue / et al.

Tapi React memberimu hak paten! Dengan kerangka kerja alternatif, Anda adalah pelanggar sejak hari pertama. Ini semua bermuara pada apakah Facebook memiliki paten dan keinginan mereka untuk menegakkannya, tetapi jika Anda ingin memperjuangkan hal ini hingga tingkat n, alternatif React lebih berisiko .

Sekarang, jika pemahaman saya benar, WordPress tidak akan meninggalkan React karena khawatir tentang lisensinya sendiri, tetapi hanya tentang harus meneruskan lisensi ini kepada penggunanya, dan karenanya membawa kebingungan dan kebutuhan untuk mempertahankan keputusan itu sendiri.

Pergi ke alternatif React, mungkin ada lebih sedikit yang harus dipertahankan jika lisensi alternatif itu permisif, tetapi mungkin juga ada beberapa kebingungan yang dibawa pada WordPress.

Terserah WordPress untuk memutuskan apakah ini sesuatu yang perlu dikhawatirkan atau tidak.

@Chrisinelli terima kasih atas kritik konstruktif Anda. Saya menyambutnya dengan tangan terbuka.

Sebagai seorang Insinyur, saya tahu biaya dan waktu berada di urutan teratas. Tapi inilah masalahnya. Ini bukan proyek Perusahaan korporat tertentu. Tujuan di sini berbeda.

Tujuannya untuk menemukan JS FW yang bagus untuk masyarakat. Gutenberg belum diluncurkan. Jika berhasil, maka Preact akan menjadi pemenang yang jelas.

Saat ini kita perlu mengurus ini:

• JS FW mudah diadopsi untuk komunitas yang lebih besar
• JS FW yang kita pilih harus memiliki komunitas dan ekosistemnya sendiri
• Rekam jejak yang terbukti dengan perangkat lunak FOSS produksi berbasis PHP merupakan nilai tambah. Vue + Laravel
• Memilih JS FW berdasarkan kelebihannya dan bukan hanya karena lebih mudah untuk dimigrasi

Dalam 11 tahun yang saya habiskan dengan WordPress, dan sebagai kontributor inti tetap, saya percaya bahwa memilih Preact akan membuat banyak kekacauan. Kurva pembelajaran sudah sangat besar untuk developer menengah / baru.

Menempatkan mereka melalui kekacauan kompatibilitas Preact-React tepat di awal fase baru peningkatan WordPress ini dapat menyebabkan mereka meninggalkan komunitas WordPress dan mempelajari hal lain dengan kurva pembelajaran yang serupa. (_HINT_: Laravel + Vue bukannya WordPress + Preact + React) Dan BTW apakah Anda lupa itu yang terjadi dengan Drupal 8?

Tolong jangan hapus komentar sipil. Jelas ada kebutuhan atau keinginan yang sangat besar untuk mengungkapkan pendapat tentang masalah ini. Saya melihatnya sebagai hal yang baik karena orang-orang mengatakan mereka peduli dengan WordPress dan mereka ingin didengarkan. Ingatlah bahwa komunitas WordPress, bukan hanya pengembangnya, diarahkan ke Github untuk memberikan umpan balik. Jika kami benar-benar tidak dapat mentolerir +1 komentar, tambahkan penghitungan di bagian atas yang mempertahankan nama pengguna.

Jika Anda hanya mencari diskusi yang beralasan, maka banyak komentar "Saya memilih X, Y, atau Z" mungkin hanya tampak seperti kebisingan, tetapi ada pola yang jelas muncul dari orang-orang yang mendukung Vue.js. Pendapat saya adalah kami memiliki ratusan, atau beberapa ratus, orang yang akan menyumbangkan kode ke Gutenberg, tetapi puluhan ribu yang akan menulis plugin dan tema yang berinteraksi dengannya. Keberhasilan Gutenberg tidak hanya menjadi pengalaman pengguna akhir, tetapi juga pengalaman pengembang. Ini bukan satu-satunya hal, tetapi satu hal penting yang membuat WordPress sukses adalah mudah dikembangkan.

Meskipun saya tidak memiliki kerangka kerja khusus, saya akan mengatakan bahwa satu hal yang harus kita ingat adalah bahwa dukungan browser mulai diterapkan dengan komponen web, kerangka kerja yang menggunakan komponen web atau setidaknya komponen mereka sendiri yang dibuat seperti mereka akan menjadi bukti masa depan. Ada juga polyfill di luar sana untuk menghadirkan komponen web ke browser yang tidak mendukungnya.

Saya disebutkan sebelumnya dan saya hanya datang ke sini untuk mematikan notifikasi, tetapi saya akan mempertimbangkan sedikit.

Jika Anda membuat aplikasi satu halaman dari awal, waktu adalah yang terpenting, dan Anda menginginkan kerangka kerja yang didukung dengan baik, didokumentasikan, dan dapat diuji, saya memiliki banyak pengalaman konkret yang menunjukkan bahwa hal itu jauh lebih murah dalam waktu dan harta untuk pergi dengan Ember.

Jika Anda membuat lebih banyak PWA atau menjatuhkan komponen ke halaman yang dirender server, Ember adalah pilihan yang buruk, dan saya dapat melihat mengapa sesuatu seperti Vue akan menarik.

Saya akan menambahkannya dari sisi konvensi yang didorong, saya telah membuat beberapa PWA dengan> 90 skor mercusuar menggunakan Ember.

Pada proyek terakhir kami di mana kami perlu melakukan ini, prosesnya membutuhkan waktu <1 jam untuk mendapatkan skor mercusuar itu dan menerapkan aplikasi dengan rendering sisi server diaktifkan.

SSR dan cache pekerja layanan yang diperlukan untuk skor mercusuar tinggi bisa menjadi proses yang sangat rumit.
Dengan Ember, proses ini sangat mudah dan hanya memerlukan instalasi beberapa add-on yang terdokumentasi dengan baik dan dipelihara (untuk sebagian besar aplikasi).
Dari pengalaman saya, Preact hadir dengan kedua fitur ini di luar kotak di CLI Preact, namun ada konvensi React (P) populer yang dapat merusak hasil SSR.
Dengan Vue, dokumen resmi merekomendasikan penggunaan Nuxt.js atau mengikuti panduan SSR lengkap ; keduanya memperkenalkan lebih banyak pola yang perlu diikuti di luar dokumentasi Vue dasar.

Tidak memberi tahu siapa pun, tapi mari kita menunda menghapus komentar tentang suatu masalah kecuali jika komentar itu sumpah serapah atau menyinggung. Saya benar-benar mendapatkan orang yang ingin membantu dan memfokuskan percakapan, tetapi kita tidak boleh terlibat dalam lingkaran menghapus komentar.

Saya tidak yakin apa yang "terdokumentasi dengan baik" tentang Ember dibandingkan dengan VueJS @rtablada .

Saya pribadi akan memiliki masalah yang dimulai dari Ember dibandingkan dengan Vue atau bahkan React.

@ahmadawais Semua orang lupa bahwa keputusan ini akan berdampak besar dan Anda tetap ingin mengubah kerangka kerja dalam beberapa tahun mendatang. Jadi Anda ingin menggunakan kebaikan kerangka modern tetapi tidak terikat padanya untuk hidup dan mati. Kedengarannya tidak mungkin? Ini bukan!

Beberapa waktu yang lalu saya mengalami masalah yang sama dan setelah penelitian dan upaya saya menemukan solusi yang mencoba menghubungkan air dengan api. Singkatnya - Elemen Kustom Komponen Web, membungkus teknologi yang Anda suka (misalnya Vue, React, Angular) dan mengekspos API DOM standar.

Dalam solusi seperti itu, Anda akan memiliki banyak komponen dan masing-masing memiliki:

• kerangka kerja yang Anda suka (tapi tentu saja sebaiknya hanya satu)
• API DOM standar yang dapat digunakan dengan mudah oleh komponen lain. Anda bahkan dapat memanipulasinya melalui JavaScipt biasa

Ketika saya bekerja dengan Vue pada waktu itu, saya menulis adaptor Elemen Kustom untuk Vue - https://github.com/karol-f/vue-custom-element - jadi Anda memiliki kompatibilitas yang superior (mis. Vue's $ emit mengirim acara DOM standar yang dapat ditangkap melalui JS biasa atau misalnya React / Angular) dan kompatibilitas IE9 +.

Saya sarankan untuk melihat solusi seperti Anda:

• akan menjadi bukti masa depan
• tidak akan terikat dengan kerangka apa pun yang Anda pilih hari ini
• pengguna Anda akan melihat elemen HTML standar dan dapat berinteraksi dengannya dengan kerangka kerja yang mereka sukai atau bahkan dengan JS biasa
• Tidak akan ada inisialisasi Vue manual karena browser akan memberi tahu Anda dan komponen init otomatis jika ada di halaman (Anda bahkan dapat memuat komponen secara malas seperti itu)

dan masih banyak lagi.

Solusi semacam itu tidak terikat dengan Vue - Anda dapat menggunakan kerangka kerja lain yang Anda suka. Juga Elemen Kustom Komponen Web adalah fitur browser standar dan tidak akan pergi ke mana pun!

Salam!

Pendapat saya adalah kami memiliki ratusan, atau beberapa ratus, orang yang akan menyumbangkan kode ke Gutenberg, tetapi puluhan ribu yang akan menulis plugin dan tema yang berinteraksi dengannya. Keberhasilan Gutenberg tidak hanya menjadi pengalaman pengguna akhir, tetapi juga pengalaman pengembang. Ini bukan satu-satunya hal, tetapi satu hal penting yang membuat WordPress sukses adalah mudah dikembangkan.

Mengutip komentar di atas oleh @dmccan karena itu poin penting dalam mendukung Vue.

WordPress telah mendemokratisasi lebih dari sekadar penerbitan. Saya bertanya-tanya berapa banyak karir dan bisnis teknologi yang sukses yang diluncurkan karena WordPress mudah didekati. Milikku, pasti.

Saya akan memberikan topi saya untuk mendukung VueJS. Pertemuan JavaScript lokal di sini dipimpin bersama oleh salah satu anggota tim inti untuk VueJS dan tampaknya orang yang hadir dapat bergabung dengan lebih cepat daripada yang lain. Pengalaman saya sebelumnya adalah dengan AngularJS dan saya menemukan VueJS sangat mudah dipelajari dan baru memulai pengkodean meskipun saya mulai dari awal.

Saya melihat beberapa orang berbicara tentang perusahaan dan Angular, tetapi sementara WordPress mungkin membutuhkan beberapa cinta di bidang itu, saya pikir keputusan harus didasarkan pada, fungsionalitas dan selain itu, kemudahan dalam pengembang yang on-boarding. Dengan diskusi yang telah kita lihat di kotak meta dan yang lainnya, membuat penulis plug-in untuk "Gutenberg-ify" bekerja alih-alih hanya meninggalkan jika / ketika editor klasik menghilang.

Beberapa poin lagi yang bagus untuk disebutkan tentang Vue.js : (Hanya pemikiran pribadi, libs lain, FWs, dan opsi dihargai dan pasti memiliki fitur dan kelebihan unik mereka sendiri)

• PRO Ini tidak selalu membutuhkan transpiler atau memaksa bagaimana cara menggunakannya dan dapat langsung dijalankan di web sebagaimana jquery bisa

Ini akan sangat membantu pengembang plugin berintegrasi dengan Wordpress UI. Mereka dapat melampirkan contoh vue baru ke bagian mana pun dari halaman sebagai widget. Juga proyek Wordpress yang besar dapat secara progresif mengadopsi dengan Vue.js tanpa perlu perubahan besar dalam basis kode karena vue tidak mengasumsikan tentang bagaimana itu akan digunakan. Saya pikir ini adalah kunci sukses mengapa Laravel / Vue sangat populer dan bekerja sama dengan baik :)

• PRO JSX dan css-in-js didukung juga!

Ini dapat membantu migrasi proyek WordPress saat ini dengan kode React / JSX lebih cepat ke vue.js dengan persyaratan perubahan yang lebih sedikit. (bahkan ada plugin babel: babel-plugin-transform-react-to-vue )

• FACT Vue seperti Preact dan tidak seperti Angular / React bukanlah proyek open source yang dimiliki oleh perusahaan besar seperti Google atau Facebook.

Ini akan menjadi sesuatu yang penting untuk proyek BESAR seperti Wordpress untuk menghindari kemungkinan vendor terkunci. Jika proyek opensource tidak dimiliki oleh perusahaan, seseorang harus memulainya (Jadi "ketergantungan orang kunci" tidak ada artinya untuk disebut sebagai CON ).

Saya memilih VueJS.
Bukan karena saya tahu apa-apa tentangnya, tapi karena saya tidak tahu bagaimana pengucapannya dalam bahasa Inggris. Namun, saya menggunakan Joomla selama bertahun-tahun dan selalu salah mengucapkannya.

Bercanda.
Tidak banyak di sini yang membahas framework apa yang lebih baik dalam mendukung metabox lama dan custom field. React sangat buruk dalam hal itu, seperti yang kita ketahui sekarang.

Sekarang, hanya untuk berhenti berlangganan dari masalah ini.

Untuk memfokuskan diskusi, saya telah membuat masalah tugas di sini: https://github.com/WordPress/gutenberg/issues/2741

Saya akan menyarankan Vue, hanya karena Laravel. Banyak orang WordPress tidak senang dengan kursus yang diambil atau masih berlangsung, telah beralih menggunakan Laravel sebagai kerangka kerja CMS utama mereka, sambil tetap mempertahankan WP sebagai pilihan kedua. Preact hanyalah tiruan dan lapisan kompatibilitas yang sangat besar, seperti Novell DOS untuk MS DOS, PC DOS dan sebaliknya.

cu, w0lf.

Vue.js sepenuhnya!

Anda pasti harus melihat Hyperapp .
Pro

1. Ini sangat mirip dengan arsitektur Elm (Model, View, Update).
2. Ini memiliki Redux built-in seperti Pengecil yang disebut "tindakan" (dipanggil untuk memperbarui model dan Tampilan pada gilirannya).
3. Menggunakan JSX
4. Mendorong desain "pemrograman fungsional"
5. Ini 1kb jadi mudah untuk memuat dan mudah dimengerti.

Kontra

1. Ini masih baru dan begitu juga dengan ekosistem. Tetapi Anda dapat mempengaruhinya dan berkontribusi padanya.
2. Mungkin ada masalah yang belum terungkap.

Prinsip blok Gutenberg cocok dengan prinsip Komponen Web . Ini level rendah, kerangka kerja agnostik dan standar yang muncul (dengan polyfill yang matang dan teruji) - sangat cocok untuk WordPress.

Lihat juga: Polimer - Komponen Web dengan sedikit gula.

Vue adalah opsi yang fantastis, dan berikut adalah alasan yang saya yakini:

Saya mulai menonton Vue pada awal 2016. Saya menyukainya dan ingin menentukan apakah Vue akan pernah "diminati" atau apakah pertumbuhannya adalah sesuatu untuk ditulis di rumah. Saat itu ia memiliki 16.000 bintang di Github. Itu keren dan semuanya, tetapi orang-orang belum benar-benar beradaptasi dengannya di tengah-tengah semua omong kosong Angular vs React.

Saya akhirnya kehilangan _semua_ data saya dan mulai lagi pada 17 September 2016. Tepat satu tahun yang lalu, hari ini. ( Ini kumpulan data saya saat ini. )

Selama setahun terakhir saya telah menyaksikan popularitas Vue tumbuh (dalam hal menyebutkan di internet dan melacak bintang Github) dengan kecepatan _record breaking_. Vue telah mengumpulkan 40.000 bintang dalam 365 hari. Itu rata-rata 109 per hari. Sebagai perbandingan, _React_ tercinta di dunia tumbuh dari 49.000 menjadi 75.000 dalam jangka waktu yang sama. (71 per hari) Vue akan melampaui React dalam beberapa bulan ke depan, dalam hal peringkat pengguna.

Sementara semua orang berbicara tentang pertumbuhan React yang paling luar biasa sepanjang masa, mereka tidak menyadari bahwa Vue adalah pemegang gelar sebenarnya. Mereka tidak menyadari bahwa Vue berkembang karena orang-orang benar-benar menyukainya sebagai alat, bukan karena dukungan terkenal (Facebook).

Vue telah berada dalam daftar repo trending Github setiap hari selama lebih dari setahun sekarang. 99% hari itu di atas Bereaksi. 10% dari hari-hari tersebut, React tidak berhasil.

Semua teriakan ini "gunakan Vue karena popularitasnya meningkat!" Tetapi yang ingin saya sampaikan adalah bahwa Vue telah berkembang karena orang-orang benar-benar menyukainya karena ini adalah alat yang hebat, intuitif, dan kuat (sering kali secara tidak tepat ditampilkan sebagai "hebat untuk aplikasi kecil") untuk aplikasi dari semua ukuran. Tapi bukan hanya alat. Vue adalah ekosistem. Itu datang dengan komunitas pendukung yang besar juga.

Bolehkah saya menambahkan ... file .vue itu jenius. Begitu banyak alat sedang dibangun untuk menangani penataan gaya di React karena tampaknya ada yang salah dengan Modul CSS dan gaya Anda di file eksternal. (Idk ...) Tapi Vue tidak memiliki masalah ini. Vue memiliki pernyataan kontrol yang dimasukkan ke dalam sintaks, dan (karena saya telah melihat komentar elemen kustom di atas) tidak hanya berfungsi baik dengan elemen kustom ... Ini _is_ pustaka / kerangka kerja untuk elemen kustom logis.

Preact sangat bagus. Sejujurnya, saya baru memulai proyek lain dengannya hari ini. Tetapi ketika saya melihat Preact, saya melihat React yang tidak sesuai dengan merek. Itu tidak dibangun untuk menjadi inovatif atau untuk memajukan cara kami membuat perangkat lunak berbasis web. Itu dibuat agar terlihat dan berfungsi seperti alat yang sudah ada sebelumnya, tetapi untuk menawarkan kinerja yang lebih baik.

Itu adalah dua sen saya. Sekarang saya bangkrut.

Saya harap keputusan akhir Anda membuat Anda bahagia dan memberikan landasan yang bagus untuk masa depan produk Anda.

@ahmadawais :

• Waktu ke pasar penting untuk proyek perusahaan dan proyek sumber terbuka. Anda dapat menemukan contoh proyek yang tidak pernah dikirimkan karena memakan waktu terlalu lama dan menjadi usang sebelum dikirim. Beberapa proyek akhirnya ditinggalkan selama pekerjaan menuju rilis besar.
• Menentang Preact berarti "kami melakukan kesalahan dengan React karena alasan di luar perizinan". Saya pikir dengan "Kurva pembelajaran sudah sangat besar untuk pengembang menengah / baru" yang Anda maksud adalah bahwa pengembang wordpress sudah kalah dengan React. Itu tidak mengejutkan saya. Namun tampaknya sulit untuk percaya bahwa Vue, meskipun tidak terlalu bertele-tele, akan menyelesaikan masalah kurva pembelajaran. Mesin PHP WP lama dan setiap javascript framework halaman aplikasi tunggal yang sangat berbeda. Vue dan React sangat mirip satu sama lain.
  Saya tidak yakin mengapa Anda melihat persaingan antara Wordpress dan Laravel. Saya mungkin naif di sini. Saya hanya tahu sedikit tentang cerita Drupal 8.
  Dari sudut pandang saya, Wordpress adalah CMS dan menarik pengembang karena basis penggunanya yang besar bukan pengguna teknis dan fitur-fitur yang sudah ada di dalamnya. Ada banyak templat dan pengembang dapat dengan cepat membangun situs baru yang dapat disesuaikan oleh bukan pengembang.
  Laravel adalah framework PHP yang, sejauh yang saya tahu, tidak memberi Anda banyak fitur CMS. Seorang pengembang akan memilihnya karena dia membutuhkan lebih banyak kebebasan.
• Saya tidak yakin bagaimana memiliki beberapa kesuksesan dengan Vue + Laravel juga berarti "Vue baik untuk Wordpress". Saya pikir ada sedikit sinergi intrinsik antara PHP dan kerangka kerja JS apa pun . Saya sepenuhnya setuju bahwa penting untuk menemukan kerangka kerja yang baik untuk komunitas. Jika sebagian besar komunitas pengembang saat ini yang menjadi tempat bergantung wordpress akrab dengan Vue dan mereka menyukainya, ini akan menjadi beban berat dalam keputusan akhir Anda.

Dari calon teknisi, saya pikir Marko JS dan Vue adalah kerangka kerja yang lebih baru. Mereka belajar banyak dari React dan mampu menghilangkan beberapa verbositas di dalamnya. Dalam hal ini Marko tampaknya menghapus lebih banyak kode boilerplate daripada Vue. Secara khusus Marko menyimpan kode kohesif yang baik untuk disimpan di tempat yang sama dan meninggalkan dalam HTML apa HTML itu bagus dan di Javascript apa kegunaan Javascript. Dan juga 10x lebih cepat. Jadi selain fakta bahwa belakangan ini Vue memiliki banyak fans, saya tidak melihat banyak alasan untuk memilih Vue daripada Marko.

Maaf, tapi sintaks dan penyiapan Marko mengerikan dibandingkan dengan VueJS. Dari segi kinerja, saya belum melihat sumber mana pun di mana MarkoJS lebih cepat dalam cara apa pun yang signifikan tanpa menambahkan waktu untuk memahami cara kerjanya.

Sintaks @ bovas85 bersifat subjektif, tetapi menurut saya tidak ada dasar apa pun dalam klaim Anda bahwa sintaks Marko adalah "perbandingan yang mengerikan". Versi Marko yang benar-benar awal memiliki sintaks yang lebih mirip dengan sintaks berbasis HTML Vue dan rilis yang memperkenalkan sintaks Marko saat ini diterima dengan sangat baik oleh pengguna kami.

Kami banyak memikirkan sintaks Marko untuk memastikannya familiar bagi pengembang yang memahami HTML dan JS dan kami ingin membuatnya sesederhana dan sekuat mungkin dengan boilerplate minimal. Saya pikir Anda akan menemukan bahwa dengan perbandingan berdampingan, templat Marko akan memerlukan lebih sedikit kode (yang sangat bagus untuk keterbacaan dan pemeliharaan).

Berikut adalah dokumen yang saya susun dengan cepat sehingga Anda dapat melihat gambaran umum tentang perbedaan antara sintaks Marko dan sintaks Vue:

Sintaks: Marko vs Vue

Saya menautkannya sebelumnya, tetapi untuk perbandingan yang lebih mendalam antara Marko dan Vue (dan React), silakan lihat:

Meetup: Membangun UI - perbandingan antara React, Vue, dan Marko (dari pencipta Marko) - Video | Slide

Untuk kinerja, kami memiliki beberapa tolok ukur yang dapat Anda periksa: https://github.com/marko-js/isomorphic-ui-benchmarks

Berikut adalah benchmark cepat dengan Marko dan Vue diaktifkan:

Performa rendering sisi server

_Node.js ( v8.4.0 ) _

Running "search-results"...

Running benchmark "marko"...
marko x 5,180 ops/sec ±2.09% (87 runs sampled)

Running benchmark "vue"...
vue x 135 ops/sec ±3.81% (68 runs sampled)

Fastest is marko

Running "color-picker"...

Running benchmark "marko"...
marko x 10,206 ops/sec ±0.72% (87 runs sampled)

Running benchmark "vue"...
vue x 1,664 ops/sec ±5.20% (66 runs sampled)

Fastest is marko

Performa sisi klien

_Chrome Versi 63.0.3218.0 (Build Resmi) canary (64-bit) _

Running "search-results"...
Running benchmark "marko"...
marko x 351 ops/sec ±1.18% (58 runs sampled)
Running benchmark "vue"...
vue x 206 ops/sec ±1.61% (57 runs sampled)
Fastest is marko

Running "color-picker"...
Running benchmark "marko"...
marko x 7,516 ops/sec ±2.90% (41 runs sampled)
Running benchmark "vue"...
vue x 4,593 ops/sec ±3.03% (54 runs sampled)
Fastest is marko

Itu adalah tolok ukur yang kami buat untuk Marko.js, jadi jelas mengambil hasil itu dengan sebutir garam, tetapi kami berusaha semaksimal mungkin untuk bersikap adil.

Juga, hanya ingin menambahkan beberapa komentar lagi tentang Marko.js dan kemudahan penggunaan:

Marko selalu bertujuan untuk memiliki integrasi paling sederhana dengan Node.js. Setelah menginstal paket marko melalui npm berikut ini semua kode yang diperlukan untuk membuat template ke aliran respons HTTP:

require('marko/node-require'); // require .marko files!

const http = require('http');
const template = require('./template');

http.createServer().on('request', (req, res) => {
  template.render({
    name: 'Frank',
    count: 30,
    colors: ['red', 'green', 'blue']
  }, res);
}).listen(8080);

Saya pikir itu sesederhana yang akan Anda dapatkan.

Marko juga bekerja dengan bundler modul JavaScript populer: http://markojs.com/docs/bundler-integrations-overview/

Untuk merender komponen UI Marko tingkat atas ke DOM di sini adalah semua yang diperlukan:

require('./fancy-button')                  // Import the Marko UI component
  .renderSync({ label: 'Click me' })   // Render the button with the provided input
  .appendTo(document.body);         // Mount the UI component to the DOM

@ patrick-steele-idem Menurut http://www.stefankrause.net/wp/?p=431 benchmark, markoJs
sama kinerjanya dengan Vue et al.

Jadi, kami dapat menyimpulkan bahwa secara umum skrip sisi klien, Markojs dan Vue sama-sama berkinerja.

Tentu saja, patokan, saya tautkan, tidak termasuk ssr. Jadi saya tidak akan berkomentar tentang itu.

Saya memilih Vue. jQuery sudah hampir menjadi persyaratan untuk menggunakan WordPress. Orang yang akrab dengan jQuery seharusnya sudah terbiasa dengan sintaks Vue. Ideologi tentang DOM tidak terlalu ekstrim seperti Angular. Itu jatuh kembali pada prinsip WordPress pada kemudahan bagi pengguna.

Seperti yang saya sarankan sekitar dua tahun lalu untuk Calypso , Mithril.js menggunakan HyperScript API akan menjadi pilihan yang baik untuk menggantikan React. Ini memiliki lisensi MIT standar.

Investasi kecil dalam alat baru untuk melakukan setidaknya beberapa pekerjaan berat secara otomatis untuk mengubah dari React ke perpustakaan vdom lain dapat terbayar dengan baik dalam penghematan jam pengembang - seperti yang disebutkan dalam masalah itu sebagai saran untuk Automattic untuk melakukan lindung nilai terlebih dahulu. taruhannya pada React.

Bahkan tanpa mempertimbangkan perpustakaan non-vdom, ada lebih dari 25 perpustakaan vdom (misalnya inferno.js, maquette, dll.) Yang dapat dipertimbangkan - seperti dalam daftar ini saya kumpulkan pada Jan 2016 untuk proyek berbeda dengan mempertimbangkan opsi vdom.

Berikut adalah beberapa alasan teknis mengapa Mithril.js atau API HyperScript adalah pilihan terbaik.

Secara pribadi, saya merasa pendekatan template untuk membuat UI yang didukung JavaScript seperti React's JSX atau pendekatan template Angular sendiri atau sistem template di banyak sistem UI lainnya termasuk Vue sudah usang. Mengapa? Preferensi dan "praktik terbaik" untuk menulis aplikasi web berbasis template HTML yang dibuat di sisi server menggunakan lembar gaya CSS yang kompleks (seperti untuk plugin WordPress sebelumnya) menjadi "praktik terburuk" untuk menulis aplikasi web satu halaman. Kebutuhan teknis untuk menulis aplikasi sisi klien satu halaman modern yang kompleks berbeda dari untuk kode berbasis server terutama karena kompleksitas yang meningkat pada kode sisi klien. Singkatnya, "praktik terbaik" lama dalam menggunakan template dan style sheet berjenjang yang kompleks tidak dapat diskalakan yang menyebabkan sulitnya pemeliharaan kode.

Apa alternatif yang muncul? Aplikasi web modern dapat menggunakan Mithril + Tachyons + JavaScript / TypeScript untuk menulis komponen dalam file tunggal di mana semua kodenya hanya JavaScript / TypeScript. Aplikasi semacam itu tidak perlu ditulis sebagian baik dalam CSS atau beberapa varian HTML non-standar yang mengimplementasikan kembali bagian dari bahasa pemrograman (buruk). (Yah, mungkin ada sedikit CSS khusus yang diperlukan di atas Tachyons atau pustaka serupa, tetapi sangat sedikit.)

Berikut adalah contoh taman bermain coding yang saya tulis seperti itu dengan beberapa contoh di dalamnya yang menggunakan pendekatan itu.

Jadi, dengan menulis UI menggunakan HyperScript (ditambah pustaka vdom), Anda berpotensi (dengan beberapa pekerjaan) mengganti backend seperti Mithril dengan hampir semua vdom lain atau bahkan solusi non-vdom. Jadi, ketika saya punya pilihan, memilih untuk menggunakan HyperScript API adalah cara saya mengurangi risiko dari pustaka dasar yang memiliki bug atau masalah lisensi.

Dengan menggunakan Tachyons atau pustaka serupa, saya mengurangi risiko file CSS yang tidak dapat dikelola saat aplikasi tumbuh.

Memang, saya tahu banyak pengembang web tumbuh dengan mengutak-atik HTML dan menyukai templat yang tampak HTML. Jadi, mereka menyukai JSX atau apa pun dan dengan senang hati mengabaikan betapa sulitnya merefaktor ulang hal-hal non-kode di tengah aplikasi mereka atau memvalidasinya. Memang, beberapa IDE menjadi lebih baik dalam refactoring template JSX. Tapi saya datang ke pengembangan web dari desktop dan pengembangan tertanam bekerja dengan sistem di mana Anda (biasanya) menghasilkan UI langsung dari kode (misalnya menggunakan Swing, Tk, wxWidgets, dan sebagainya). Saya menyukai gagasan bahwa alat standar dapat membantu saya memfaktor ulang semua kode yang saya kerjakan dan mendeteksi banyak ketidakkonsistenan.

Dengan asumsi bahwa semua kerangka kerja yang dijalankan di sini tidak memiliki perbedaan yang terlihat oleh pengguna karena kecepatan mereka di browser pilihan mereka, kami dapat berhenti menggunakan kinerja frontend sebagai metrik untuk mengevaluasi kerangka kerja mana yang merupakan pilihan terbaik.

Tetapi jika kita menggunakan rendering sisi server, kita harus hati-hati melihat kinerja SSR. Calypso tampaknya bertujuan untuk memiliki RSK. Dan jika berhasil, suatu saat Calypso akan menjalankan sebagian besar situs di wordpress.com.

Perusahaan membayar CPU di server, bukan CPU di browser. Jadi dari perspektif biaya, waktu rendering Marko 10x lebih cepat kemungkinan besar berarti bahwa lalu lintas yang sama yang maksimal 10 server dengan MarkoJS, sebenarnya akan mengambil setidaknya 100 server yang menjalankan Vue.

Jika Wordpress dapat mengabaikannya, saya akan dengan senang hati datang bekerja untuk perusahaan dan mendapatkan gaji pasar 10x dan menggunakan Vue yang menurut saya adalah alternatif React yang baik =)

Semakin ringan kerangka kerjanya - yaitu, semakin sedikit fungsionalitas yang ditawarkan di luar kotak - semakin cepat kinerjanya. Ini sangat jelas. Membandingkan kinerja berbagai algoritme adalah satu hal, tetapi jika faktor terbesarnya adalah seberapa banyak "hal" lain yang dilakukan, Anda tidak perlu menulis tes.

https://hueniverse.com/performance-at-rest-75bb8fff143

@ahmadawais Tim inti Angular di sini - kami sedang mengerjakan banyak pekerjaan menarik terkait dengan pengembangan gaya CMS / Widget, termasuk berinvestasi dalam dukungan Elemen Kustom (yang, untuk uang saya, adalah taruhan masa depan yang cerdas untuk membangun platform)

Daripada mengacaukan utas lebih jauh, kami akan dengan senang hati mengobrol dengan Anda semua secara offline, jika Anda tertarik. Kirimi saya pesan di robwormald di google dot com. Semoga berhasil dalam hal ini, saya tidak iri Anda harus melakukan panggilan ini ;-)

Saya telah membuat jajak pendapat sederhana di sini yang dapat digunakan untuk mendapatkan wawasan tentang apa yang diinginkan orang-orang ..

sedang mengerjakan halaman hasil & autentikasi. (baru mengenal firebase)

PS. membutuhkan waktu sekitar 1 jam untuk membuatnya menggunakan Vue 🖖

@vinayakkulkarni Bagaimana kalau menambahkan Mithril.js ke polling Anda?

@pdfernhout : 👍

Selesai. Saya telah menambahkan MithrilJS ke daftar.

• [x] VueJS
• [x] Sudut
• [x] Berlangsung
• [x] Ember
• [x] Marko
• [x] Inferno
• [x] Aurelia
• [x] Mitrhil

Mari kita lihat apa yang orang putuskan ..
PS. Ada juga polling twitter oleh @ahmadawais .

Hai. Saya adalah pemelihara inti Drupal. Seperti yang disebutkan @ivanjaros dalam komentar sebelumnya, kami juga mengevaluasi Preact, Vue, atau yang lainnya, untuk beberapa bit UI admin Drupal yang akan datang. Kami mungkin memutuskan sesuatu yang berbeda dari apa yang Anda pilih, tetapi apa yang Anda pilih pasti akan menjadi setidaknya satu faktor untuk kami pertimbangkan dalam pilihan kami.

Sejauh ini saya telah membuka dua masalah Drupal, dan lebih banyak lagi yang akan datang. Cukup rujuk silang di sini jika masalah / diskusi itu berguna bagi Anda.

• komponen yang mengembalikan banyak node root
• slot vs. props vnode

Perhatikan bahwa saya masih sangat menyukai Vue, terlepas dari dua masalah itu. Itu mungkin hal-hal yang tidak masalah bagi kita, untuk mendapatkan semua manfaat lain dari Vue.

Sebagai penulis Vue, saya akan menghindari memberikan komentar tentang kerangka apa yang harus dipilih di sini karena saya jelas bias; tetapi ketika saya melihat pernyataan bahwa "Marko 10x lebih cepat dari Vue" dilontarkan beberapa kali, saya merasa itu perlu klarifikasi. Saya juga tidak ingin menggagalkan pembahasan menjadi debat teknis, jadi saya telah menuliskan beberapa pemikiran dalam inti ini untuk mereka yang tertarik.

@ michaelbdavidson7 mengenai masalah keuangan: Saya telah bekerja penuh waktu di Vue selama lebih dari 1,5 tahun sekarang dan dukungan Patreon sangat stabil. Daripada berspekulasi tentang fluktuasi janji Patreon, Anda dapat memeriksa aktivitas komitmen Vue untuk menilai sendiri. Selain itu: memiliki saluran kontribusi keuangan terbuka berarti WP / Automattic dapat dengan mudah memastikan keberlanjutan Vue dengan menjadi sponsor utama (Matt sendiri sudah menjadi sponsor pribadi!) - yang sebenarnya sejalan dengan kepentingan kedua proyek.

Saya memilih Vuejs

@ tungbt94 Mengapa?

Pasti VueJS

Pertanyaan yang lebih besar, mengapa bereaksi dipilih sebelum masalah paten ini. Jika tidak ada paten, apakah Anda masih menggunakan react? Banyak poin yang dibuat tentang TIDAK memilih preact sama dengan tidak memilih bereaksi.

Pilihan saya adalah dengan Preact

Karena saya tidak memiliki banyak pengalaman dengan hal lain selain React, saya tidak akan mempertimbangkan framework apa yang harus dipilih.
Namun, menurut saya argumen "komunitas besar" adalah salah satu yang kurang penting. Mengapa? karena ketika Automattic memutuskan kerangka kerja, pekerjaan pertanian itu akan mendapatkan ribuan pengguna baru. Dan jika saya tahu komunitas WP benar, banyak dari mereka akan mulai berkontribusi pada kerangka itu juga dan popularitas akan meningkat.

Mengingat posisi Gutenberg dan Calypso saat ini, menurut saya Preact adalah pilihan teknik terbaik.

Namun, jika Anda masih merasa kuat tentang membakar jembatan dengan kemiripan dengan React atau jika Anda harus memulai dari awal, saya masih percaya MarkoJs adalah pilihan terbaik. Saya pikir dukungan komunitas mungkin masih menjadi perhatian.

Dengan asumsi bahwa bintang Github entah bagaimana berkorelasi dengan komunitas, Vue masih 10x dibandingkan dengan MarkoJ tetapi melihat grafiknya, itu akan berubah dengan cepat.

Vue tumbuh secara linier:

Tetapi MarkoJ tampaknya berada pada titik perubahan dari pertumbuhan eksponensial:

@ patrick-steele-idem, penulis utama MarkoJs , selalu sangat responsif di https://gitter.im/marko-js/marko

Ketika orang akhirnya memilih MarkoJs , tetapi benar-benar jenis komunitas apa pun, saya ingin mengutip kutipan JFK: "Jangan tanya apa yang dapat dilakukan komunitas untuk Anda - tanyakan apa yang dapat Anda lakukan untuk komunitas."

Secara pribadi saya ingin mengucapkan selamat kepada @ahmadawais karena telah membuat satu masalah yang telah menciptakan interaksi yang signifikan dari banyak JS Dev yang menggunakan dan mendukung opsi JS Library yang relevan.

Saya menduga masalah ini telah membantu menginformasikan lebih banyak JS Devs tentang pergerakan WordPress menuju lebih banyak pengembangan berbasis JavaScript melalui Gutenberg daripada komunikasi Gutenberg lainnya sejauh ini.

Saya menggunakan AngularJS tetapi yang tidak saya suka adalah pembaruan utama setiap kali, jadi saya akan menggunakan VueJS.

1 untuk Marko. Perpustakaan hebat yang digunakan tim kami dan sangat menyenangkan. Rendering asinkron, super cepat (merender ke string di server dan ke vdom di browser), komponen tunggal atau multi-file, dan IMO sintaks template terbaik di luar sana.

Harap pertimbangkan hyperHTML @WebReflection .

Saya suka Angular

Saya memilih Angular

Saya Memilih Angular

hanya bersudut

Saya Memilih Angular

bersudut

Saya memilih Angular

Saya memilih Angular

Jika Anda ingin memilih kerangka kerja, alangkah baiknya mengetahui alasan pastinya dan bagaimana hal itu membantu Gutenberg.

Kepada orang-orang yang datang ke sini hanya untuk mengatakan "Saya memilih X", tolong beri kami beberapa alasan mengapa kami harus memilih X juga. "Saya memilih X" tidak memberi tahu kita apa pun selain bahwa Anda menyukai X.

Saya memilih sudut. Angular memiliki beberapa perubahan besar sejak versi2. Sekarang, ini adalah kerangka kerja yang sepenuhnya, bagus, kuat dan banyak digunakan。 Karena, seperti ionik, belajar tidak cepat, tetapi dengan kuat.

Dengan banyaknya spam “I Votekerangka kerja ”, github mengoceh untuk saya.

Saya mendorong rekan-rekan pengembang untuk memilih kerangka kerja pilihan Anda di https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ daripada hanya memposting 'Saya memilih…';

Juga, saran lain adalah mengunci percakapan ini; sebagian besar pengembang besar telah menyatakan pendapatnya tentang hal ini.

Pada 18-Sep-2017, pada 20:01, Mingyue [email protected] menulis:

Saya memilih sudut. Angular memiliki beberapa perubahan besar sejak versi2. Sekarang, ini adalah kerangka kerja yang sepenuhnya, bagus, kuat dan banyak digunakan。 Karena, seperti ionik, belajar tidak cepat, tetapi dengan kuat.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 .

terima kasih @kidwm untuk menyebutkan _hyperHTML_, tapi saya rasa lebih baik mengikuti arahan mereka:

Jangan hanya membagikan framework JS yang Anda suka, tetapi juga membagikan alasannya

jadi izinkan saya mencoba melakukan itu ...

: zap: hyperHTML :

• PRO : Ramah pemula dan familiar bagi pengguna P / React (alih-alih JSX, Anda menulis Template Literals)
• PRO : sangat cepat dan tanpa VDOM; konsumsi memori lebih sedikit (ramah ponsel di pasar negara berkembang)
• PRO : Tidak memerlukan alat (hanya memerlukan literal template transparan untuk IE <11)
• PRO : Sepenuhnya berdasarkan standar JS / DOM / HTML tetapi juga kompatibel dengan TypeScript
• PRO : cocok dalam waktu kurang dari 5K (min-zip) tanpa perlu polyfill tambahan atau patch browser
• PRO : Cakupan kode 100% hingga ke kebiasaan IE9
• PRO : berbagi API yang sama dengan mitra NodeJS ; 100% perenderan sisi server kompatibel
• PRO : dapat mengadopsi DOM yang ada tanpa merusak tata letak / node SSR
• PRO : bekerja dengan Elemen Kustom lebih baik daripada P / React, ini juga dapat digunakan untuk menentukan Elemen Kustom
• PRO : dapat melakukan apa yang dilakukan React , Vue.js , Polymer , Angular , atau Marko , dan menang dalam hal ukuran / bandwidth / kinerja masing-masing

Sekarang, sesuai dengan metrik yang digunakan sejauh ini di utas ini, CONS

• CONS : meskipun telah diuji dalam pertempuran, sepenuhnya dalam pengujian, dan dengan API yang dibekukan, ini adalah proyek yang relatif muda (Maret 2017) sehingga tidak dapat bersaing dalam hal popularitas, adopsi, atau jumlah kontributor
• CONS : komunitas sangat membantu dan proyek berkembang, tetapi kontributor teknis utama sejauh ini adalah saya. Saya 100% berkomitmen untuk proyek ini, dan bersedia untuk mendorongnya sebanyak yang saya bisa, ditambah lagi saya berdiskusi dengan beberapa "_bigs_" tentang penggunaan _hyperHTML_ dalam beberapa proyek besar berikutnya (saya tidak akan berspekulasi lebih lanjut meskipun jadi jangan ragu untuk mengabaikan bagian terakhir ini)

: dart: Saya benar-benar percaya bahwa masa depan Web adalah menggunakan platform ini sebanyak mungkin, yang secara pasti jauh lebih baik daripada 10 tahun yang lalu, dan berkat spesifikasi ECMAScript modern, cara lebih mudah untuk menulis, membaca, dan memelihara. _hyperHTML_ mewakili "kondisi _current seni Web_" dalam hal potensi, sementara setiap pesaing lain dalam daftar ini lahir sebelum era ES6 penuh.

Saya memahami ukuran komunitas, kontributor, dan bintang GitHub itu penting, tetapi menurut saya tes, cakupan kode lintas browser, dan jumlah bug, juga harus dipertimbangkan, dan saya melakukan yang terbaik untuk menjaga jumlah _hyperHTML_ dan teman-teman dekat nol (sebenarnya nol sekarang, di samping diskusi yang bukan bug).

Terakhir, namun tidak kalah pentingnya, jika tidak ada yang memberi solusi baru kesempatan dan menilai hanya berdasarkan bintang dan hype, solusi baru akan membutuhkan waktu lebih lama dari yang seharusnya untuk menjadi lebih populer.

Tentu saja, saya telah berbicara tentang solusi terbaru saya, pertimbangan saya mungkin dianggap subjektif, tetapi khususnya kalimat terakhir saya tentang memberi kesempatan pada solusi baru, sangat umum, bukan hanya tentang perpustakaan saya: smiley:

Salam Hormat

Saya suka bersudut

harus bersudut dan google.

Saya suka sudut

Angular hanyalah kerangka nyata!

Saya memilih Angular, bukan AngularJs.

Hanya sudut yang merupakan kerangka nyata!

Saya mulai curiga, komentar ini dibuat oleh bot.

@OP : Harap kunci utas ini.

Saya memilih Angular (BUKAN AngularJS).

Angular adalah platorm, tim google melakukan banyak pekerjaan hebat untuk membuat kemajuan pengembangan lebih mudah, termasuk komponen, modul, router, dengan injeksi ketergantungan, Anda dapat menghemat banyak pekerjaan untuk mengatur semua ketergantungan, dengan angular-cli, Anda dapat menghemat banyak pekerjaan untuk memulai proyek baru, Anda cukup membuka kotak dan aplikasi Anda terkompilasi dengan baik dengan aot, gemetar pohon, dan banyak pengoptimalan lainnya.

TypeScript adalah alat hebat lainnya dengan sudut, ini disediakan oleh MicroSoft, alias seluruh platform sudut dibangun dengan ts. Anda juga membangun aplikasi Anda dengan ts! Ini adalah alat yang hebat untuk membuat hidup lebih mudah ketika jumlah kode semakin besar, Anda dapat melakukan pemfaktoran ulang di IDE (seperti vscode) hanya dengan satu klik. Pemeriksaan tipe statis membuat Anda menemukan bug sedini mungkin. TS juga menyediakan implementasi OOP yang baik, Anda dapat mengatur dan menggunakan kembali kode Anda dengan cara yang jauh lebih baik.

Ada juga banyak komponen yang dibangun berdasarkan sudut, seperti desain meterial2, primeng, dan saya ingin merekomendasikan Anda Jigsaw , yang dibuat oleh tim kami. Ini diadopsi oleh Produk Big Data ZTE China. Ini mendukung semua aplikasi ZTE sekarang.

Anglar adalah pilihan yang bagus !!

Untuk semua bot: 🖕

Mungkin seseorang memposting di komunitas AngularJs. Saya pikir orang dapat menonaktifkan utas jika mereka tidak ingin menerima pesan lagi.

Saya pikir pada akhirnya percakapan serupa tentang topik ini harus terjadi di tempat yang hanya ada kontributor WordPress.

Saya ingin berbagi beberapa pemikiran saya tentang masalah ini yang sebagian besar sudah saya ungkapkan di kelompok komunitas kendur EmberJS, jika Anda memiliki 10 menit untuk membaca diskusi di sana, saya akan merekomendasikannya: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 Ada cukup banyak di sana, tetapi saya sangat menyarankan untuk memeriksanya untuk mendapatkan pemahaman yang berbeda tentang diskusi.

Poin utama saya dalam diskusi itu adalah sebagai berikut:

• Saat membandingkan lonjakan 2-4 minggu dalam mengimplementasikan sesuatu dalam kerangka Ember vs Library lainnya, perpustakaan lain cenderung menang dalam jangka pendek tetapi Ember menang untuk proyek jangka panjang.
• Saat mempertimbangkan perpustakaan atau kerangka kerja mana yang akan digunakan, penting untuk tidak hanya mempertimbangkan implementasi teknis tetapi juga aspek "soft skill" (ukuran komunitas, komitmen untuk mendukung LTS, keterlibatan komunitas dalam keputusan inti proyek)
• Ember memiliki rekam jejak dalam memberikan perbaikan besar pada aplikasi yang dibangun menggunakan ember-cli "di bawah tenda" yaitu tanpa perlu memperbarui kode aplikasi apa pun. Ada juga kasus peningkatan kecil pada kode aplikasi (dengan menyertakan kode-mod menggunakan hal-hal seperti ember-watson ), Anda mendapatkan peningkatan kinerja dan produktivitas yang signifikan.

Saya tidak ingin membahas terlalu banyak detail dalam komentar ini karena saya dapat dengan senang hati menulis esai 10.000 kata tentang poin-poin di atas. Namun, saya ingin menawarkan waktu saya kepada siapa saja yang ingin mendiskusikan masalah ini dengan seseorang yang memiliki "pola pikir Ember".

Jika ada di antara para pembuat keputusan yang ingin menelepon saya selama satu jam untuk menanyakan pertanyaan yang lebih tajam tentang ekosistem Ember yang lebih luas, saya akan dengan senang hati melakukannya. Anda dapat menghubungi saya di Twitter saya (DM terbuka). Saya mungkin bukan anggota tim inti tetapi saya telah membangun aplikasi Ember sejak sebelum 1.0 dan telah melalui semua proses peningkatan dengan berbagai aplikasi 👍

Saya bekerja untuk "My eBay" di eBay. Kami baru saja merilis aplikasi satu halaman pertama kami. Kami menikmati setiap fase pengembangan menggunakan MarkoJS. Seperti saya, jika Anda menyukai paradigma pemrograman streaming node maka MarkoJS mendukung streaming dan rendering asinkron. Fakta lain yang saya suka tentang MarkoJS:

• pengikatan efisiennya atas perilaku komponen UI yang dirender di server dan di browser.

• Pendelegasian acara yang sangat efisien

• Serialisasi status yang cepat dari server ke browser

@vinayakkulkarni Saya pikir ide Anda bagus, tetapi masalahnya adalah saya dapat memberikan lebih dari 1 suara dengan mengganti browser (saya belum mencoba dengan browser yang sama).

Anda mungkin harus menggunakan polling twitter (tapi sudah ada) atau menerapkan sistem login untuk membuat suara unik.

Rendering server tidak relevan dengan percakapan di sini. Node tidak akan menjadi bagian dari tumpukan WordPress yang diperlukan, jadi seberapa cepat kerangka kerja ini dirender di Node tidak relevan dengan keputusan.

Vue.js! lihat proyek ini https://github.com/bstavroulakis/vue-wordpress-pwa

Saya memilih Angular (bukan AngularJS), ia memiliki komunitas terbesar, ekosistem yang stabil dan lengkap.

Angular sangat lambat dan dengan v4 berdasarkan skrip, tidak berguna untuk pengembangan wordpress ..

Saya memilih Angular berdasarkan kematangan platform

Saya akan memilih Vue karena lebih mudah untuk mempelajarinya dan karena kerangka favorit saya Ember Js terlalu besar untuk pekerjaan itu & Glimmer Js masih terlalu baru. :-)

Rendering server tidak relevan dengan percakapan di sini.

dalam kasus saya, saya baru saja menyebutkan fitur yang menurut orang lain relevan

Node tidak akan menjadi bagian dari tumpukan WordPress yang dibutuhkan

_hyperHTML_ dapat mengambil konten yang dirender di sisi server, termasuk PHP. Saya seorang insinyur bersertifikat Zend, dan saya telah bekerja dengan jurnalis / penerbit menggunakan WordPress, petunjuk saya tidak begitu saja.

jadi seberapa cepat framework ini merender di Node tidak relevan dengan keputusan.

Fakta bahwa kerangka kerja juga berfungsi pada backend, dapat mengambil konten yang dirender di sisi server, dan bahkan akan kompatibel dengan NativeScript mungkin merupakan nilai tambah yang tidak relevan saat ini, tetapi fitur yang kompatibel di masa depan, seperti yang mungkin dipertimbangkan oleh proyek berpikiran terbuka.

@webreflection Saya tidak bermaksud bahwa komentar itu

Melihat

@mAAdhaTTah dari https://ma.tt/2017/09/on-react-and-wordpress/ :

Posting itu tidak akan dipublikasikan, dan sebagai gantinya saya di sini untuk mengatakan bahwa tim Gutenberg akan mundur selangkah dan menulis ulang Gutenberg menggunakan perpustakaan yang berbeda. Ini kemungkinan akan menunda Gutenberg setidaknya beberapa minggu, dan dapat mendorong rilis ke tahun depan.

Dan yang lebih penting:

Automattic juga akan menggunakan apa pun yang kami pilih untuk Gutenberg untuk menulis ulang Calypso

Calypso sudah menggunakan rendering sisi server. Lihat: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

Jadi pemahaman saya adalah kinerja RSK itu relevan.

Saya juga suka sudut！
AngularJS js kerangka nyata！

Saya memilih Angular

@chriscinelli Itu Automattic, bukan WordPress. WordPress sendiri tidak melakukan rendering server dengan node, jadi kinerja dalam kondisi tersebut tidak relevan dengan proyek.

Jelas, Angular adalah pilihan terbaik

Saya memilih Angular

Saya memilih Angular

Saya memilih Vue.js.
Ini menghemat sebagian besar waktu, terutama saat berhadapan dengan lapisan tampilan.

Saya harus memilih Vue !!!

Keluarkan gelombang sudut

@trotyl Komentar itu tidak bisa diterima. Saya telah mengedit komentar Anda untuk menghapusnya.

oh, tolong jangan AngularJS
sekarang Angular.

@mAAdhaTTah Dari wikipedia:

WordPress dirilis pada 27 Mei 2003, oleh pendirinya, Matt Mullenweg dan Mike Little sebagai garpu b2 / cafelog

Meskipun sebagian besar dikembangkan oleh komunitas di sekitarnya, WordPress terkait erat dengan Automattic , perusahaan yang didirikan oleh Matt Mullenweg.

Ini Calypso: https://developer.wordpress.com/calypso/ dan Calypso menggunakan SSR.

Seperti yang saya tulis di komentar saya menjatuhkan dukungan ReactJS oleh Matt bahwa mereka ingin menjaga Gutenberg dan Calypso selaras pada teknologi yang sama. Automattic akan menyajikan halaman Calypso dari server mereka dengan SSR.

Saya rasa ini cukup untuk membuat kinerja RSK relevan dalam keputusan ini.

Namun di masa depan yang jauh, setelah pengembang Wordpress terbiasa dengan Preact (atau Vue atau Marko atau kerangka kerja lain), proyek gila baru mungkin akan keluar dan mereka memutuskan untuk melayani lebih banyak bagian Wordpress melalui node. Itu akan membuat RSK menjadi lebih penting. Jadi kinerja RSK mungkin lebih penting.

Karena percakapan telah beralih untuk membahas SSR, saya pikir adalah bijaksana untuk menyebutkan bahwa ini adalah prioritas yang sangat tinggi untuk Ember dan telah dipikirkan secara ekstensif dengan munculnya Ember-Fastboot

Meskipun saya menggunakan Fastboot (untuk efek yang hebat) dengan beberapa aplikasi klien karena ini adalah diskusi teknologi tingkat tinggi, saya akan merekomendasikan untuk menghubungi @tomdale karena dia adalah juara untuk upaya Fastboot 👍

@chriscinelli WordPress proyek komunitas dan Automattic perusahaan masih merupakan entitas yang terpisah. Jika Automattic ingin membantah satu sama lain karena SSR, mereka bisa, tetapi masih tidak mengubah cara kami, komunitas WordPress, harus mempertimbangkan kerangka kerja pilihan untuk inti WordPress, yang tidak, dan benar-benar tidak bisa, membutuhkan node untuk dijalankan.

Bagaimanapun, saya telah berhenti berlangganan utas ini. Jika Anda ingin melanjutkan diskusi ini secara offline, email saya ada di profil saya.

tidak, dan benar-benar tidak bisa, membutuhkan node untuk dijalankan.

tolong jangan jadikan kemampuan RSK sebagai hal yang membedakan. Kerangka kerja yang mampu membuat SSR node dapat hidup tanpa node SSR sama sekali: ini hanya fitur tambahan, bukan persyaratan, atau ketergantungan.

Saya akan memilih Vue.js

Saya seorang arsitek senior yang kuliah di MIT dan seharusnya cukup pintar. Saya telah melakukan ini selama bertahun-tahun dan saya telah mewawancarai beberapa pengembang di sana-sini. Saya tahu web penuh dengan orang-orang pintar, tetapi siapa pun yang berpikir bahwa kesederhanaan Vue setara dengan kompleksitas Angular telah kehilangan perspektif tentang apa yang disebut "kompleks". Javascript berbasis komponen, seperti yang dipahami Google, sama sekali tidak sepele. Ini sangat rumit. Vue tidak. Vue semudah PHP. Saya mengatakan yang sudah jelas, karena "Vue lebih mudah dipelajari" bahkan tidak TUTUP untuk menggambarkan betapa lebih mudahnya Vue daripada Angular. Dan inilah tangkapannya-- Saya pikir ini juga jauh lebih mudah daripada React.

React berada di garis antara easy-peasy dan google-level, untuk orang biasa. Untuk toko kecil, menurut saya React cukup kompleks untuk menantang tim kecil. React lebih kompleks dari, misalnya, PHP / Wordpress. Dengan memilih React, Wordpress / Automattic menaikkan persyaratan untuk masuknya pengembang ke dunia pengembang Wordpress. Saya yakin ratusan orang akan berteriak, "Bereaksi itu mudah" dan "Web semakin pintar", tetapi yang lebih kompleks masih lebih kompleks, pada akhirnya.

Saya dengan rendah hati berpikir bahwa pindah kembali ke Vue akan lebih dekat dengan akar WP, dan lebih sedikit beban teknis pada komunitas WP secara keseluruhan. Selain paradigma web-- terkadang, sederhana itu bagus.

Angular dan Vue adalah 2 hal yang berbeda

Vue, React, MarkoJS, Inferno, Preact dll adalah pustaka yang mencakup hanya lapisan tampilan. Semuanya termasuk Angular memiliki cara untuk membuat HTML dan memutasi DOM dengan cara deklaratif. Angular ingin menyediakan kerangka kerja lengkap untuk pengembangan frontend dan memiliki lebih banyak hal di luar lapisan tampilan.

Sintaks React adalah yang tertua dalam sampel ini. Facebook melakukan pekerjaan yang cukup baik untuk mengikat perpustakaan yang sangat kompleks yang melakukan banyak hal (mungkin terlalu banyak) di permukaan protokol yang sangat terbatas. Anda tidak perlu mengetahui kerumitan apa pun di dalam React untuk mengetahui cara menggunakannya dan menjadi produktif dengannya. Anda dapat benar-benar mempelajari dasar dan mulai menggunakan dalam setengah hari.

Setiap perpustakaan lain dalam daftar ini belajar dari React. Mereka mencoba menyederhanakan sintaks, meningkatkan kinerja React, mengurangi ukuran kode Javascript yang diperlukan untuk melakukan hal yang sama dan menambahkan beberapa fitur di atasnya.
Preact melakukan pekerjaan yang bagus untuk menjaga antarmuka yang sangat mirip dengan React hanya dalam 3Kb.
Inferno dan Marko mengoptimalkan penampilan rendering secara masif.
Marko dan Vue banyak menyederhanakan sintaks untuk mengurangi kode boilerplate.
Marko juga menambahkan sintaks seperti Jade / Pug opsional untuk menjaga kode lebih KERING dan kemampuan untuk membuat template asinkron yang menjaga semuanya tetap sederhana dan intuitif bagi pengguna.

Namun semua pustaka di samping Angular ini membutuhkan para insinyur untuk keluar dengan strategi dan mekanisme untuk mengambil data, perutean, dll. Redux dan middlewaresnya adalah salah satu cara populer yang digunakan Gutemberg untuk mengelola lapisan data.

Dalam migrasi dari React, Gutenberg tidak membutuhkan "hanya hal lain untuk diubah". Bahkan jika Angular berusaha untuk tetap agnostik bagi pengguna, menggunakannya dengan Redux dan Javascript (vs Typescript) bukanlah pilihan yang wajar meskipun perpustakaan seperti https://github.com/angular-redux/ng-redux dikembangkan dan mendukung untuk Javascript tersedia. Lebih jauh melihat voting sejauh ini, tampaknya komunitas Gutenberg sangat menentang kerangka kerja Google. Jadi kemungkinan besar Angular tidak akan menjadi pilihan.

PHP dan salah satu kerangka Javascript ini adalah binatang yang sangat berbeda

Anda dapat memiliki backend PHP dan frontend aplikasi satu halaman tetapi tidak ada sinergi dan sedikit kesamaan.

Setiap aplikasi Javascript setidaknya satu urutan kerumitan di atas apa yang Anda dapat menulis kode PHP biasa yang ditaburi beberapa jQuery. Semua aplikasi Javascript Modern harus berurusan dengan dua monster kompleksitas besar: statefulness dan aliran asynchronous . Mereka hanya dimitigasi oleh kekekalan dan async / await dalam beberapa tahun terakhir ini. Alur pengembang menjadi lambat saat aplikasi berkembang. Saat Anda mengubah beberapa kode, Anda perlu mengkompilasi ulang, memulai ulang dan aplikasi harus melalui inisialisasi lagi. Jumlah perkakas yang sangat besar telah dibangun untuk mengimplementasikan hot reload dan bahkan jika mengagumkan, mereka masih jauh dari sempurna.
Tidak peduli perpustakaan apa yang Anda pilih untuk lapisan tampilan, Anda harus berurusan dengan kerumitan ekstra.

Di PHP Anda mengubah kodenya, Anda menyimpan file dan Anda dapat segera memuat ulang halaman tanpa membangun atau memuat ulang. Semuanya bekerja. Dan yang lebih penting, PHP sepenuhnya tanpa kewarganegaraan . Setiap kali Anda memuat ulang halaman, Anda memiliki batu tulis kosong. Bahkan variabel global memiliki status bersih dengan setiap permintaan (tetapi ini bukan alasan yang baik untuk menggunakannya = P). Saya belum pernah menulis kode PHP dalam beberapa tahun tetapi saya masih merindukan kesederhanaan dan pengalaman pengembangnya. Jika Anda menggunakan kerangka kerja modern seperti CakePHP, Symphony atau Laravel, Anda tidak akan ketinggalan banyak dibandingkan dengan bahasa dan kerangka kerja lain yang lebih disambut oleh para insinyur canggih. Pengecualiannya adalah kecepatan. PHP membayar kesederhanaannya dengan kinerja runtime. Setiap kali Anda memuat ulang halaman, semua kode perlu dijalankan lagi. Performa meningkat pesat dengan HHVM dan PHP7 tetapi secara umum mereka masih jauh dari apa yang dapat Anda capai dengan node.js.

Kesimpulan

Tidak masalah library apa yang baru-baru ini Anda gunakan untuk frontend. Bahkan jika Anda menyukainya, bukan berarti itu pilihan terbaik untuk Gutenberg.
Fakta bahwa _ sebagian besar kontributor inti Gutenberg_ mungkin menyukai satu perpustakaan tertentu adalah penting.

Pada akhirnya:

Seorang pria yang yakin bertentangan dengan keinginannya masih memiliki pendapat yang sama

Saya pikir ada cukup banyak informasi di utas ini tentang pro dan kontra dari berbagai perpustakaan yang layak.

Kontributor Gutenberg dan Wordpress harus dibiarkan sendiri mungkin bertemu di "pintu tertutup", jauh dari fanboy frontend.
Mungkin sudah waktunya untuk mengklarifikasi nilai, tujuan dan kendala yang Anda miliki dan memilih kerangka kerja berdasarkan apa yang memaksimalkan hasil Anda.

Dan semoga sukses lagi dengan keputusan Anda 😃

Saya memberikan suara saya untuk Vue. Ramah pemula dan tangguh. Ketika saya pertama kali mulai menggunakan Vue, saya merasakan perasaan itu ketika saya pertama kali mulai mengembangkan dengan WordPress. + 💯

@ warna-warni hanya ramah pemula tidak cukup baik! Setiap proyek memiliki lingkaran kehidupan, sebagian besar pekerjaan sedang dalam proses pemeliharaan.

@ChrisCinelli Beberapa klarifikasi dan opini:

Angular ingin menyediakan kerangka kerja lengkap untuk pengembangan frontend dan memiliki lebih banyak hal di luar lapisan tampilan.

Vue memiliki pustaka resmi untuk perutean, manajemen status, pengujian, linting, dan lainnya, plus alat cli resmi. Semua itu berada di bawah organisasi vuejs, dipelihara oleh anggota inti dan tetap sinkron dengan Vue itu sendiri, tetapi bagian terbaiknya adalah Anda tidak perlu mempelajari atau menggunakannya (karena itu filosofi 'Kerangka Kerja Progresif'). Tidak seperti React, ini secara efektif menjadikannya kerangka kerja dalam bentuk resminya. Sedikit pelesetan: semua ini masih lebih mudah dipelajari, lebih cepat dan lebih ringan dari Angular. :tersenyum:

Marko juga menambahkan sintaks seperti Jade / Pug opsional

.vue file dapat menggunakan preprocessor apapun untuk template, script atau style (misalnya pug, skrip ketikan, coffescript, sass, stylus ...). Gunakan yang paling sesuai dengan proyek Anda!

membutuhkan insinyur untuk keluar dengan strategi dan mekanisme untuk mengambil data

Ini hanyalah sebuah contoh, tetapi mengambil data tidak perlu direkayasa secara berlebihan:

async created () {
  const result = await fetch('/api/items')
  this.items = await result.json()
}

Dari sana Anda dapat membuat plugin Vue yang sangat sederhana untuk membuat kode lebih ringkas.

Vue sendiri seharusnya tidak menjadi pustaka yang tepat untuk pekerjaan ini karena akan selalu ada pustaka khusus yang lebih baik (ini juga mengapa kami tidak menawarkan filter tanggal secara default misalnya, karena Anda akan berakhir menggunakan momen atau pustaka hebat lainnya sebagai gantinya) . Kami juga sedang dalam proses menulis buku masak dengan jalur dan praktik yang direkomendasikan untuk beberapa kasus bisnis dan penggunaan.

Saat Anda mengubah beberapa kode, Anda perlu mengkompilasi ulang, memulai ulang dan aplikasi harus melalui inisialisasi lagi.

Satu-satunya perbedaan nyata adalah langkah pembuatan, yang saat ini mudah diatur menggunakan alat seperti vue-cli atau poi resmi. Saat Anda menyimpan file, aplikasi hampir langsung siap untuk di-refresh (waktu build juga sangat bagus untuk proyek besar, dan dari pengalaman mengembangkan aplikasi PHP besar menggunakan kerangka kerja seperti Symfony lebih menyakitkan). Selain itu, fitur Penempatan Modul Panas adalah nilai tambah besar yang tidak ada di dunia PHP (sepengetahuan saya) dan memungkinkan kode baru tersedia untuk pengujian di browser dalam waktu yang hampir instan bahkan dalam proyek besar (kecuali Anda punya operasi mahal seperti kompilasi Sass - tetapi Anda akan memiliki masalah yang sama saat menggunakan PHP). Omong-omong, Vue mendukung HMR webpack dengan sangat baik .

Anda harus berurusan dengan kerumitan ekstra.

IMHO, beberapa framework PHP yang sangat populer tampaknya lebih kompleks dan lebih sulit untuk dipelajari daripada beberapa library / framework frontend seperti Vue. (Kebalikannya juga sangat benar.)

Berdasarkan pengalaman saya selama 2 tahun lebih dalam membuat editor berbasis blok yang mirip dengan Gutenberg, saya pikir ada beberapa masalah yang harus ditangani saat memilih kerangka kerja yang tepat, mis.

• Bagaimana VueJS / Marko / Angular terintegrasi dengan drag & drop? Bagaimana cara kerja drag & drop di Gutenberg? Saat menyeret, apakah Anda menggandakan elemen hantu atau menggunakan elemen yang ada? Saat menjatuhkan, di mana Anda dapat memasukkan placeholder untuk melepaskan blok?

• Bagaimana VueJS / Marko / Angular (dan Virtual DOM-nya) bekerja dengan Content Editables dan DOM Range & Selection API? Inkonsistensi lintas browser dengan rentang & pilihan ini bisa sangat sulit untuk dipakukan di sini.

• Sampai sejauh mana salin / potong / tempel akan berfungsi di editor Gutenberg? Dapatkah saya membuat pemilihan teks di antara beberapa blok dan melakukan pemotongan / salin / tempel? Apakah konten yang dapat diedit tinggal di setiap blok individu atau apakah semuanya terkandung dalam konten master yang dapat diedit?

• Jika ada blok Gutenberg yang berisi embeddable iframe, misalnya menyematkan pemutar youtube atau feed twitter di postingan blog, memindahkan blok ini dari satu posisi DOM ke posisi lain akan menyebabkan iframe dimuat ulang sendiri. Peringatan lainnya termasuk ketidakmampuan untuk menyebarkan peristiwa dari iframe kembali ke editor (bayangkan jika Anda menyeret elemen blok ke editor dan kursor Anda sekarang melayang di iframe lintas situs dan semuanya berhenti bekerja).

Semua kerangka kerja hebat dalam bekerja dengan DOM Virtual, tetapi banyak penggunaan WYSIWYG tinggal di luar DOM Virtual. Saya pikir area yang harus difokuskan saat menilai kerangka kerja yang tepat untuk Gutenberg adalah seberapa baik kerangka kerja menangani penanganan peristiwa DOM, dan untuk persyaratan terdepan yang tidak dapat dibangun dengan kerangka kerja, seberapa mudah dikelola untuk membangunnya di luar kerangka kerja dan pasang kembali.

melihat

Wordpress cukup mudah untuk dipelajari oleh para pengembang baru dan juga banyak kekuatan jika Anda melihat lebih dalam, hal yang sama dapat dikatakan untuk Vue.
Saya akan senang jika WP menggunakan kerangka ini!

Pilihan saya adalah VUE!

Dalam hal membangun komponen web khusus, yang menurut saya cukup penting untuk kedepannya, situs ini memberikan skor untuk setiap kerangka kerja yang terdaftar dengan parameter uji dan skor. Ini instruktif, jadi akan mendorong semua orang untuk memberikannya sekali:

https://custom-elements-everywhere.com/

Pilihan saya untuk VueJS. Kerangka kerja yang luar biasa, saya pikir Laravel membuktikannya.

WP + Sage 9 (roots.io) + VueJS => tumpukan sempurna

Mungkin ada masalah dengan Preact juga.

https://blog.cloudboost.io/3-points-to-consider-before-migrating-away-from-react-because-of-facebooks-bsd-patent-license-b4a32562d268

Menggunakan Preact mungkin membuat Anda lebih buruk daripada menggunakan react. Facebook akan diizinkan untuk memblokir Anda dari menggunakan react atau preact bahkan jika Anda tidak mengajukan gugatan. Pengacara ini tampaknya berpikir Preact tidak akan dapat mempertahankan hak ciptanya di pengadilan dan akan dianggap melanggar reaksinya.

Beritahu saya jika saya salah. Saya tidak tahu banyak tentang hukum tetapi ingin membantu.

Saya membaca ini dan ini mirip dengan nasihat hukum yang kami dapatkan setelah memutuskan
meninggalkan React dalam proyek kami. Bukan karena risikonya besar. Melainkan kami
ingin meminimalkan risiko bagi klien hilir. Pengacara ini hanya menambahkan
pendapat yang sama. Kami menggunakan Polymer dan Vue sebagai gantinya, keduanya bekerja dengan baik
untuk kasus penggunaan tertentu.

Pada 20 Sep 2017 pukul 23:04, [email protected] menulis "Coding Friend":

Mungkin ada masalah dengan Preact juga.

https://blog.cloudboost.io/3-points-to-consider-before-
bermigrasi-jauh-dari-bereaksi-karena-dari-facebooks-bsd-
paten-lisensi-b4a32562d268

Menggunakan Preact mungkin membuat Anda lebih buruk daripada menggunakan react. Facebook akan menjadi
diizinkan untuk memblokir Anda dari menggunakan react atau preact bahkan jika Anda tidak memulai
gugatan. Pengacara ini tampaknya berpikir Preact tidak akan bisa bertahan
itu hak cipta di pengadilan dan akan dianggap melanggar bereaksi.

Beritahu saya jika saya salah. Saya tidak tahu banyak tentang hukum tetapi ingin membantu.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

Saya bersumpah pada diri sendiri saya tidak akan pernah menyentuh WP lagi setelah melihat kode yang mengerikan, tetapi jika Anda menggunakan VueJS, saya mungkin mempertimbangkannya kembali dengan sedikit Valium.

Penafian: Saya bukan pengacara. Berikut ini adalah pendapat saya.

@ codingfriend1 artikel itu memiliki sedikit manfaat praktis.

Ada tiga asumsi yang dibuat:

1. Facebook memiliki paten yang cukup luas untuk mencakup preact.
2. Jika sebuah perusahaan menggunakan preact, katakanlah ABC, menuntut FB atas pelanggaran paten, maka FB akan menggunakan hak paten react untuk menuntut ABC.
3. Paten Facebook memang bermanfaat.

Mari kita lihat lebih dekat semua asumsi:

1. Facebook memiliki paten yang cukup luas untuk mencakup preact.

Tidak ada bukti ini sampai saat ini. Ingatlah bahwa semua paten bersifat publik. Kode sumber Preact adalah pengetahuan umum.
Selain itu, Jason Miller (penulis preact) telah mengklaim bahwa "tidak ada Preact yang dapat dipatenkan - itu terlalu jelas."

Jadi saya akan mengatakan asumsi ini tidak mungkin benar. Itu mungkin, tapi tidak mungkin.

1. Jika sebuah perusahaan menggunakan preact, katakanlah ABC, menuntut FB atas pelanggaran paten, maka FB akan menggunakan hak paten react untuk menuntut ABC.

Ini akan menghancurkan reputasi Facebook. Meskipun saya berharap FB berjuang mati-matian, tetapi menggunakan paten react seperti itu akan memberi label FB sebagai "patent troll".

Padahal, FB memiliki sumber daya yang cukup untuk berjuang menggunakan sarana hukum. Jadi saya yakin asumsi ini juga tidak mungkin.

1. Paten Facebook memang bermanfaat.

Ya, ini asumsi, bukan fakta.

Kebetulan, "memiliki paten" dan "memiliki paten yang sah" adalah dua hal yang berbeda.
Saya membaca artikel yang fantastis ini di mana pengadilan telah memutuskan bahwa paten tidak valid.

Selalu ada kemungkinan paten FB terlalu luas untuk diritensi.
Sekarang orang akan berpikir bahwa, jika facebook memiliki hak paten, itu akan menjadi keuntungan _some_. Namun, secara logika, jika mencakup preact ,, maka itu terlalu luas dan karenanya tidak bermanfaat. Jadi asumsi ini bertentangan langsung dengan asumsi 1.

Mengingat Facebook menggunakan paten untuk membela diri, paten Facebook lebih cenderung luas dan tidak bermanfaat, daripada dapat diterapkan.

Kesimpulan:

Ingatlah bahwa ketiga asumsi tersebut belum teruji. Jika semuanya ternyata benar, - dan ini secara teknis memungkinkan-- maka, "ya, menggunakan preact itu berbahaya."

Namun secara praktis, kemungkinan ketiga asumsi tersebut benar terlalu rendah, terutama asumsi 1 dan 3 bersama-sama.

Jadi sampai dan kecuali pengadilan mengatur sebaliknya, saya akan mengatakan menggunakan preact (dan perpustakaan vdom lainnya) cukup aman.

Mengenai poin 1, Facebook memiliki paten yang disebut Delegasi acara efisien dalam skrip browser . Itu pada dasarnya jQuery live() fungsi (kemudian menjadi bagian dari on() di jQuery API)!

Namun, terlepas dari validitas asumsi tersebut, alasan WordPress beralih dari React bukanlah karena WordPress memiliki kekhawatiran tentang Facebook. Dan saya mengutip dari posting pengumuman yang ditautkan dalam masalah di atas ( sorot milik saya):

Saya pikir klausul Facebook sebenarnya lebih jelas daripada banyak pendekatan meyakinkan dunia bahwa klausul paten Facebook baik-baik saja bukanlah tugas kami.

Berdasarkan hal ini, persepsi, kebingungan, dan pertanyaan yang dibawa oleh patenlah yang membuat WordPress menjauh. Saya pikir masalah yang sama juga berlaku untuk Preact, seperti yang dijelaskan dalam komentar saya sebelumnya .

Mengenai poin 1, Facebook memiliki paten yang disebut Delegasi acara efisien dalam skrip browser. Itu pada dasarnya adalah fungsi live () jQuery (kemudian menjadi bagian dari on () di jQuery API)!

Apakah itu berarti mereka yang menemukan ide delegasi acara ?! Saya melihat beberapa kutipan di sana yang berasal dari tahun 1995, apa artinya?

@ChrisCinelli tentang apa yang Anda sebut sebagai apa yang "tampaknya menjadi titik perubahan dari pertumbuhan eksponensial" dalam kasus Marko.

Saya percaya ini hanyalah masalah skala. Ketika sebuah proyek memiliki 5k atau bahkan 10k bintang Github, satu kejadian seperti misalnya tautan di halaman atas Hackernews dapat menghasilkan 1k bintang dalam sehari, yang dalam kasus Marko adalah 20% dari angka terbaru.

Pada skala 65k bintang yang dimiliki Vue, itu tidak terlalu terlihat. Anda bahkan dapat melihatnya karena cara kerja skrip riwayat bintang, pada titik tertentu ia berhenti menunjukkan fluktuasi sama sekali dan itu hanya garis lurus sampai akhir.

Situasi seperti ini tidak hanya terjadi pada Marko sendiri, terjadi pada Inferno atau akhir-akhir ini pada MoonJS yang merupakan microframework yang terinspirasi oleh Vue. Anda bahkan dapat mengatakan bahwa Preact tampaknya berada di titik yang sama karena berapa banyak bintang yang didapatnya akhir-akhir ini karena keseluruhan drama paten React.

Anda dapat mengamati apa yang saya bicarakan pada grafik berikut dari sumber yang sama seperti milik Anda:

Waktu akan memberi tahu apakah orang-orang ini benar-benar akan mencoba kerangka kerja dalam pengembangan, menggunakannya dalam produksi, dan terus menggunakannya nanti. Saya berharap Marko baik-baik saja, seperti setiap perpustakaan sumber terbuka lainnya.

Adapun Vue, ya itu pertumbuhan yang stabil tanpa fluktuasi yang besar. Dengan kecepatan saat ini, seharusnya React top sebelum Natal. Setidaknya di Github. :)

Bagaimana dengan @aurelia?
Situs web: aurelia.io
@Eisenbergect membuat ini.

Bagi saya ini adalah kerangka kerja yang bagus!

1. Konvensi Sederhana (dapat disesuaikan)
2. HTML biasa
3. Vanilla JS
4. Tidak Ada Intervensi Kerangka Kerja!

Anda bahkan dapat memasukkan pustaka pilihan Anda (jQuery, Vue.js, Preact, Ember, HyperHTML, dll ...) yang ingin Anda gunakan dan ajarkan Aurelia cara menggunakannya!

Ini sangat sederhana dan berdasarkan standar Anda bahkan tidak memerlukan dukungan komunitas, dan jika Anda benar-benar menganggap dukungan komunitas itu penting maka mereka juga membantu Anda (dengan lebih dari 10k bintang).

Sumber daya untuk @aurelia :

1. Memperkenalkan Aurelia
2. Blog Aurelia
3. Aurelia Docs

Sepertinya React sedang diberikan lisensi di bawah MIT: https://code.facebook.com/posts/300798627056246

Keputusan harus dibalik sekarang, saya kira.

Holly Molly! React kembali bekerja. WordPress melakukan itu? Tidak yakin! Ini jam 3 pagi dan saya sangat bersemangat tentang ini! Bagaimana denganmu!

Relicensing React, Jest, Flow, dan Immutable.js

Minggu depan, kami akan melisensikan kembali proyek open source kami, React, Jest, Flow, dan Immutable.js di bawah lisensi MIT. Kami memberikan lisensi ulang untuk proyek ini karena React adalah fondasi dari ekosistem perangkat lunak open source yang luas untuk web, dan kami tidak ingin menahan kemajuan karena alasan non-teknis.

Keputusan ini diambil setelah beberapa minggu mengalami kekecewaan dan ketidakpastian bagi komunitas kami. Meskipun kami masih yakin lisensi Paten BSD + kami memberikan beberapa manfaat bagi pengguna proyek kami, kami mengakui bahwa kami gagal meyakinkan komunitas ini secara meyakinkan.

Di tengah ketidakpastian tentang lisensi kami, kami tahu bahwa banyak tim menjalani proses pemilihan library alternatif untuk React. Kami minta maaf atas kesalahannya. Kami tidak berharap untuk memenangkan tim-tim ini kembali dengan melakukan perubahan ini, tetapi kami ingin membiarkan pintu terbuka. Kerja sama dan persaingan yang bersahabat di ruang ini mendorong kami semua maju, dan kami ingin berpartisipasi penuh.

Pergeseran ini tentu saja menimbulkan pertanyaan tentang proyek open source Facebook lainnya. Banyak proyek populer kami yang masih memiliki lisensi BSD + Patents untuk saat ini. Kami juga mengevaluasi lisensi proyek tersebut, tetapi setiap proyek berbeda dan opsi perizinan alternatif akan bergantung pada berbagai faktor.

Kami akan menyertakan pembaruan lisensi dengan rilis React 16 minggu depan. Kami telah mengerjakan React 16 selama lebih dari setahun, dan kami telah sepenuhnya menulis ulang internal untuk membuka fitur-fitur canggih yang akan menguntungkan semua orang yang membangun antarmuka pengguna dalam skala besar. Kami akan segera berbagi lebih banyak tentang cara kami menulis ulang React, dan kami berharap pekerjaan kami akan menginspirasi pengembang di mana pun, baik mereka menggunakan React atau tidak. Kami tidak sabar untuk melupakan diskusi lisensi ini dan kembali ke hal yang paling kami minati: mengirimkan produk hebat.

Menurut pendapat saya, dengan Lisensi MIT dan dengan komunitas JS open source yang paling aktif dan terbesar di belakangnya - React adalah pilihan yang pasti untuk digunakan.

Pilihan saya kembali dengan React sekarang . - Keyakinan pada kemanusiaan dipulihkan.

Beri suara dengan 👍 alih-alih komentar serupa.

Saya ingin mengucapkan TERIMA KASIH BESAR saya untuk Wordpress karena telah mengambil bagian dalam apa yang menyebabkan perubahan dalam React lincencing ini.

Saya masih berpikir Vue akan menjadi solusi yang lebih baik. Banyak kekuatan dari Vue masih berlaku, tetapi saya ingin menunjukkan bahwa keramahan pemula dan tidak harus menggunakan langkah build, menurut pendapat saya, adalah fitur yang mematikan di lingkungan wordpress.

untuk misa
tentunya
untuk vueJS

Saya juga memilih Angular2.0 + (bukan AngularJS), yang memiliki komunitas terbesar, tim pengembang yang kuat, ekosistem yang stabil dan lengkap.

@CrazyBBer Di mana saya dapat menemukan beberapa data tentang komunitas terbesar Angular 2/4? Ini akan membantu saya dengan posting blog.

Ngomong-ngomong, semuanya sudah berakhir, React akan tetap menggunakan WordPress dan bahkan sebagai penggemar Vue, saya menemukan cara terbaik untuk mengubah situasi, mengingat jumlah kode yang sudah ditulis dengan React.

@ahmadawais @gustojs orang di Reddit telah menyampaikan kekhawatiran bahwa MIT hanya mencakup hak cipta sehingga pengembang TIDAK akan memiliki hak paten saat menggunakan React yang saya anggap masih menjadi masalah.

Juga pernyataan ini benar-benar mengganggu saya:

kami mengakui bahwa kami gagal meyakinkan komunitas ini secara meyakinkan.

Secara efektif mengatakan "Kami tidak salah - Anda pengembang hanya tidak memahami kami".

@ahmadawais : Saya masih berpikir menggunakan Vue akan menjadi pilihan yang lebih baik karena Anda telah melihat contoh sempurna bagaimana lisensi React yang berubah-ubah, pertama mereka memiliki BSD + Patents license sekarang, beralih ke MIT. Siapa tahu dalam waktu dekat mereka mungkin beralih kembali ke beberapa Lisensi / Paten milik FB dan kemudian semua orang akan digantung untuk mengeringkan. Vue telah menjadi MIT sejak awal dan lebih didorong oleh komunitas daripada yang digerakkan oleh perusahaan besar.

Ditambah apa yang dikatakan @ atanas-angelov-dev.

Tidak ada gunanya beralih sekarang.
Saya pikir Vue menawarkan perspektif yang lebih baik tetapi itu berarti menulis ulang segalanya

Ahh! Ayo semuanya, beri Aurelia kesempatan ya!
Itu dibuat oleh salah satu pengembang utama dari tim Angularjs.
Anda dapat beralih dari adopsi kecil ke kerangka penuh seperti Vue.js

Bahkan tim portal @azure mengatakan jika mereka akan memulai sekarang, mereka akan memilih Aurelia daripada KO!
Dan siapa yang tahu ?! mereka mungkin akan berpindah ke Aurelia sedikit demi sedikit sekarang.

Mulailah sedikit, saya tahu Anda akan menyukainya!

Nirmal4G,
Tesis Anda terdengar sangat menjual sehingga konyol.
Sebenarnya saya yakin keseluruhan kerangka kerja memiliki kekurangan yang sama dengan halaman 404 yang Anda tautkan secara langsung di posting Anda.
http://aurelia.io/get-started.html

@ bovas85 Tidak menjual, saya bahkan bukan bagian dari tim itu. Mereka bahkan tidak tahu saya menggunakan kerangka mereka.

@ cr4m / cc

Jangan menilai buku dari sampulnya

Saya telah menggunakan banyak kerangka kerja populer bahkan sebelum saya tahu tentang Aurelia. Jika saya harus menumpuknya dengan menyeimbangkan setiap kriteria di luar sana, untuk aplikasi saya (percayalah, Ini adalah aplikasi besar) maka Aurelia berada di puncak daftar dan diikuti oleh Vue.

Saya percaya keseluruhan kerangka kerja memiliki kekurangan yang sama dengan halaman 404 yang Anda tautkan secara langsung di posting Anda.

Setiap link yang saya posting tidak pernah masuk ke halaman 404. Itu kesalahan github karena mengarahkan http ke situs https. Sudah diperbaiki sekarang. Lihat, seekor serangga. Beri tahu saya kerangka apa pun yang tidak memiliki bug, saya tantang Anda.

Hanya saja dengan kerangka kerja lain Anda memiliki banyak abstraksi yang mubazir (namun berguna). Komunitas W3C tidak pernah mengadopsi desain kerangka kerja publik di API mereka, jadi begitulah, Banyak abstraksi.

Setiap kerangka sangat fokus pada kompatibilitas mundur sehingga kehilangan kompatibilitas ke depan tetapi Aurelia tidak melakukan itu, selama Anda tetap berpegang pada spesifikasi HTML W3C dan ECMAScript, JS kode Anda berfungsi dengan baik.

_Jika tidak ada Aurelia maka saya tidak akan keberatan menempel pada Vue. Itu hal terbaik berikutnya._

_Ini hanya masalah menerima standar daripada menciptakan cara baru untuk menemukannya kembali._

@ Nirmal4G harap berikan bukti klaim Anda atau hindari nama. Saya hampir tidak percaya, terutama jika menyangkut LOC, Vue kurang dari hyperHTML. Semua yang saya tulis dalam hyperHTML dibandingkan dengan vue kurang LOC, menyusun tata letak dan logikanya . Meskipun saya bahkan tidak percaya pada LOC sebagai metrik yang relevan dengan apa pun, membaca FUD yang tidak terbukti tampaknya tidak adil bagi saya.

@WebReflection Pegang

Aplikasi saya menggunakan semua yang bisa Anda lakukan. Saya mencoba prototipe dengan banyak kerangka kerja, salah satu kriteria yang saya miliki adalah LOC tetapi dari sudut pandang visual, Ini bukan karena alasan Anda berpikir, kinerja kerangka apa pun dapat ditingkatkan tetapi itu adalah pilihan desain, yang datang dengan namanya.

Saya mengevaluasi HyperHTML, Kinerjanya mengesankan, tidak ada polyfill yang bagus, tetapi sayangnya untuk persyaratan saya itu tidak berhasil.

Setiap kerangka memiliki satu hal yang lebih baik, Harapan saya adalah bahwa jika ada yang dapat menggabungkan yang terbaik dari semua kerangka di luar sana dengan desain yang lebih baik itu akan menjadi ilahi, tetapi itu tidak akan terjadi. Jadi, saya harus menemukan keseimbangan itu di mana kerangka kerja dapat meningkatkan dirinya sendiri di masa depan dan di tempat yang tidak.

Senang sekali mendengar bahwa React sekarang akan menjadi MIT.
Membuat saya sangat bersemangat dengan proyek ini dan saya berharap untuk mulai menggunakan WordPress lagi setelah waktu yang lama, setelah React dan WP API akan didukung sepenuhnya. :)

Mari kita tunggu dan lihat apa lisensi React yang sebenarnya. MIT, atau MIT + Patents ..? ;)

Secara pribadi saya suka React tetapi menemukan Vue lebih produktif. Aku akan senang dengan keduanya, tapi ...

... mengingat dukungan kuat untuk Vue oleh komunitas, saya sarankan untuk mempertimbangkannya, selain perizinan.

Vue sepertinya menjadi pilihan yang lebih tepat untuk WordPress.

Facebook telah menghapus 4 item dari rangkaian perangkap litigasi mereka. Ini sekarang semua berlisensi MIT:

• Reaksi
• Bersenda gurau
• Mengalir
• Immutable.js

Sementara itu, lisensi Kategori X Facebook masih berlaku untuk:

• React Native
• GraphQL
• Benang
• Menyampaikan
• IDE Atom
• dan kemungkinan apa pun yang dibuat oleh mereka dan bersumber "terbuka"

Saya masih mengatakan pergi dengan Vue. Itu sangat berharga dalam jangka panjang. React tidak pernah masuk akal bagi saya untuk Wordpress. Ini sangat tertanam dalam komunitas PHP, Vue selalu tampak seperti pilihan yang paling masuk akal (ditambah itu tidak menyakitkan untuk digunakan seperti React).

Sementara itu, lisensi Kategori X Facebook masih berlaku untuk:

React Native
GraphQL
Benang
Menyampaikan
IDE Atom
dan kemungkinan apa pun yang dibuat oleh mereka dan bersumber "terbuka"

@TheJaredWilcurt maaf tapi Anda mungkin ingin menghapus benang dari daftar itu .. benang tidak memiliki lisensi "Kategori Facebook X" -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

Orang-orang di Reddit telah menyuarakan keprihatinan bahwa MIT hanya mencakup hak cipta sehingga pengembang TIDAK akan mendapatkan hak paten saat menggunakan React yang menurut saya masih menjadi masalah.

MIT adalah lisensi yang bagus. jQuery juga berlisensi MIT. Saya harap Anda tahu itu.

@vinayakkulkarni Saya masih berpikir menggunakan Vue akan menjadi pilihan yang lebih baik karena Anda telah melihat contoh sempurna bagaimana lisensi React yang berubah-ubah, pertama mereka memiliki lisensi BSD + Patents sekarang, beralih ke MIT. Siapa tahu dalam waktu dekat mereka mungkin beralih kembali ke beberapa Lisensi / Paten milik FB dan kemudian semua orang akan digantung untuk mengeringkan. Vue telah menjadi MIT sejak awal dan lebih didorong oleh komunitas daripada yang digerakkan oleh perusahaan besar.

Bukan begitu cara kerjanya. Saya membaca komentar Samuel di Facebook untuk pertanyaan serupa. Setelah Anda melisensikannya MIT, Anda dapat mem-forknya untuk mengubah lisensinya atau Anda tidak bisa. Saya bukan seorang pengacara.

Juga, secara pribadi saya pikir Facebook telah melakukan ini sebagai isyarat niat baik dan bukan untuk menipu orang. Itu berarti bagi saya.

Juga, secara pribadi saya pikir Facebook telah melakukan ini sebagai isyarat niat baik dan bukan untuk menipu orang. Itu berarti bagi saya.

Itu bukanlah pernyataan yang sangat logis. Anda memberi penghargaan kepada satu kelompok karena mereka berhenti melakukan sesuatu yang negatif, daripada memberi penghargaan kepada kelompok yang tidak pernah melakukan hal negatif sama sekali. Juga, seperti disebutkan di atas, mereka masih menggunakan lisensi Kategori X dalam proyek serupa lainnya, yang bukan merupakan pertanda niat baik bagi saya.

Vue memiliki kurva pembelajaran & adopsi yang BANYAK lebih lembut.
Dan itu telah menjadi ide dasar utama WordPress sejak awal.

@ahmadawais Saya tahu - MIT sebagus lisensi yang didapat tetapi, dan ini adalah "tapi" yang besar, Facebook tampaknya memiliki paten di React dan sementara MIT memungkinkan Anda menggunakan kode untuk tujuan apa pun, Anda mungkin masih melanggar Facebook paten (ambil semua ini dengan sebongkah garam - IANAL)

Dan untuk tetap pada topik, saya harus mengatakan saya melihat banyak hal yang membuat WordPress hebat di Vue juga - menurut pendapat saya tidak ada perpustakaan lain yang cocok yang mudah dipelajari dan digunakan seperti Vue.

Facebook ternyata memiliki hak paten atas React

bagian mana dari React yang menurut Anda dipatenkan? (tidak ada di React yang dipatenkan, coba lakukan riset dulu) tampilkan link, bukan hanya "tampaknya" .., ini adalah jenis komentar yang tidak membantu sama sekali. Jika Anda ingin merekomendasikan perpustakaan favorit Anda lakukan dengan cara yang benar, tunjukkan manfaatnya, bukan hanya menyebarkan FUD.

Mengapa pindah ke BSD + Paten jika tidak ada React yang memiliki paten di belakangnya? Facebook belum mengatakan apa itu, atau bukan.

Mengapa dipusingkan dengan perizinan selama 2 tahun dan hanya membuat perubahan untuk sebagian dari portofolio mereka, setelah secara konsisten mengatakan mereka tidak akan mengubahnya, dan mengatakan "urus saja, kami tidak peduli jika Anda menggunakannya atau tidak".

Mengapa mengecualikan React Native, GraphQL dll dari lisensi "baru"? Apa versi React masa depan yang akan digunakan? Tidak ada jaminan jika Anda memiliki lisensi dua tingkat dari Facebook, tergantung siapa yang mengeluhkannya ...

Bagaimana jika bagian dari kode React Native dimasukkan ke dalam React. Di mana Anda berdiri jika implementasi GraphQL bekerja menuju basis kode ..?

Tindakan oleh Facebook ini menimbulkan lebih banyak pertanyaan daripada jawabannya, dan tetap berarti bahwa setiap penggunaan React merupakan risiko potensial untuk proyek Open Source yang sebenarnya.

Cukup adopsi perpustakaan tanpa bagasi yang sudah mapan di dunia PHP - Vue.

@bjrmatos https://www.google.com/patents/US20170221242 Saya kira!

Satu lagi +1 untuk Vue. Facebook masih menggunakan dua lisensi di seluruh proyek mereka. Itu tidak baik.

@PericlesSouza Anda jelas mengabaikan upaya besar yang dilakukan perusahaan seperti facebook untuk memperbaiki keadaan dan memajukan web, semua pertanyaan Anda dapat dijawab jika Anda baru saja membaca posting tentang perubahan ke MIT. Saya tidak begitu tahu mengapa Anda masih mengemukakan kekhawatiran irasional ini dengan lisensi MIT, dengan perubahannya, React berada pada posisi yang sama dengan proyek "True Open Source" lainnya (saya tidak tahu apa yang Anda sebut proyek True Open Source btw).

@Raymonf baiklah, pada dasarnya semua kerangka modern di luar sana telah melanggar paten itu (termasuk Vue) sehingga siapa pun berada di posisi yang sama tidak peduli apakah Anda menggunakan React, Vue atau kerangka kerja lain yang mengimplementasikan konsep yang dijelaskan dalam tautan (btw pada dasarnya web apa pun proyek di luar sana sudah melanggar dua atau tiga paten yang dimiliki oleh perusahaan lain, Anda akan terkejut mengetahui hal-hal seperti apa yang dipatenkan oleh perusahaan saat ini). Jika Anda benar-benar khawatir tentang itu, itu berarti Anda tidak dapat menggunakan kerangka kerja apa pun yang memperbarui UI dengan cara itu .. jadi dalam konteks hukum ini tidak ada alternatif yang lebih baik atau lebih buruk.

Saya tidak ingin terlibat dalam percakapan semacam ini lagi karena tidak mungkin mencapai kesepakatan jadi saya akan menghentikan komentar saya. Komunitas React senang dengan perubahan ke MIT (bahkan para pengkritik lebih besar dari lisensi aslinya)

Semoga sukses untuk tim wordpress dalam keputusan ini, masalah utama tentang lisensi React BSD + Patents telah diselesaikan, sekarang tugas mereka untuk memutuskan.

Jadi Facebook baru saja mengubah lisensi mereka untuk React. Apakah itu berarti WordPress akan terus menggunakan React atau masih mengubah kerangka front end default?

@bjrmatos ini tidak benar sama sekali

pada dasarnya semua kerangka modern di luar sana sudah melanggar paten itu

misalnya, hyperHTML tidak menggunakan DOM virtual, ia menggunakan API DOM secara langsung (tidak dapat dipatenkan) melalui panggilan panggilan balik biasa (tidak dapat dipatenkan) dan satu-satunya algoritme yang berbeda untuk mengubah c hildNodes: sebelum menjadi c hildNodes: setelah dalam daftar node didasarkan pada jarak Levenshtein (tidak dapat dipatenkan) dan jumlah operasi sambungan paling sedikit (tidak dapat dipatenkan, saya menulisnya dan itu ISC ).

Dan sementara pada titik ini saya pikir utas ini sudah usang dan tidak berguna, saya tidak mengerti perlunya terus menyebarkan FUD. Jika Anda membuat pilihan dan Anda menyukainya, tidak ada alasan untuk memberi tahu orang lain bahwa mereka melakukan kesalahan atau berada dalam masalah yang sama dengan Anda. Saya berharap kami bisa menyetujui ini.

@noncotient itu pertanyaan jutaan dolar, bukan? 💯

Saya baru saja berhenti berlangganan di sini karena diskusi menjadi sedikit tidak berguna.
Saya pikir banyak poin bagus yang dimajukan dan ini merupakan pengalaman belajar bagi semua orang yang membaca dengan cermat masalah ini.

Saya setuju, ini sekarang tidak ada gunanya. Saya menyarankan utas ini dikunci (atau mungkin hanya Kontributor). Ada cukup banyak tanggapan tentang masalah ini, dan sekarang telah mencapai titik di mana ia hanya akan mengarah pada argumen yang tidak konstruktif.

Apakah masalah ini akan ditutup?
Sepertinya @WordPress tidak tertarik untuk bermigrasi ke Kerangka JavaScript baru sekarang. 🤔

Bagi saya, saya pribadi menyukai @vuejs. Tapi sepertinya itu tidak masalah sekarang. 😅

Secara pribadi saya lebih memilih Vue.

Bagi saya, dan saya percaya banyak orang lain, ini tidak pernah tentang perizinan. Ini hanyalah alasan untuk menjauh dari React.

Marko sangat kuat dan mudah. Kami saat ini sedang menyelesaikan penulisan ulang lengkap dari toko web dinamis dengan 50.000 produk dan fitur tersebut sangat berkobar dan sangat mendalam. Ikuti rute ini dan jangan melihat ke belakang.

Marko bagus tetapi Prarko 100 byte lebih kecil (GZipped), dan 0,01% lebih cepat pada pengujian yang dioptimalkan sendiri, jadi kita harus menggunakannya sebagai gantinya, bahkan jika tidak ada orang lain yang melakukannya. Meskipun besok Plarko akan dirilis, dengan tambahan Fiber, yang membuat _everything_ mubazir.

Maaf, tapi begitulah tujuan utas ini.

Mari kita tunggu dan lihat apa lisensi sebenarnya ketika keluar, apa implikasi dari lisensi dua tingkat Facebook, dan lihat keputusan apa yang diputuskan oleh tim WordPress setelah mereka menyelidiki masalah ini secara menyeluruh.

Maksud saya, awalnya minta masukan tentang mesin yang disukai masyarakat. Dan sepertinya itulah yang diposkan orang, namun beberapa orang melompati banyak orang karena mengirimkan komentar yang sejalan dengan apa yang diminta. Agak aneh.

Semua perpustakaan / kerangka kerja yang disebutkan di sini sangat baik; beberapa lebih cocok untuk beberapa skenario daripada yang lain. Masing-masing akan memiliki pendukungnya, masing-masing akan melompati yang lain dalam hal kinerja / fitur, tergantung pada siklus pengembangan mereka.

Mungkin mulai dengan pertanyaan sederhana, seperti yang saya lakukan pada sebagian besar proyek:

1. Apakah kita membutuhkan kerangka SPA?

Jika jawabannya ya, jelaskan alasannya. Itu memberi Anda seperangkat kriteria untuk mengevaluasi calon potensial; mungkin untuk rendering sisi server, mungkin perutean, dll.

Jika tidak, tanyakan pertanyaan berikutnya:

1. Apakah yang kita butuhkan adalah template engine?

VanillaJS memiliki komunitas terbesar di planet ini, dan tidak ada masalah perizinan. Ini juga sesuai dengan standar;), dan dengan modul ES6, mungkin menawarkan dasar yang sesuai untuk pengembangan inti, dengan kemampuan untuk mendukung plugin untuk menggunakan mesin _template_ seperti React, Vue, Preact, Aurelia dll dll. Apa pun yang akan dirilis di tahun-tahun mendatang, seperti yang dipersyaratkan oleh pengembang.

Matt Mullenweg memposting tanggapannya ...

Saya terkejut dan senang melihat berita bahwa Facebook akan mencabut klausul paten yang saya tulis minggu lalu. Mereka telah mengumumkan bahwa dengan React 16 lisensi hanya akan menjadi MIT biasa tanpa tambahan paten. Saya memuji Facebook karena melakukan langkah ini, dan saya berharap penggunaan klausul paten diperiksa ulang di semua proyek open source mereka.

Keputusan kami untuk menjauh dari React, berdasarkan sikap mereka sebelumnya, telah memicu banyak diskusi menarik di dunia WordPress. Khususnya dengan Gutenberg, mungkin ada pendekatan yang memungkinkan pengembang untuk menulis blok Gutenberg (Gutenblocks) di perpustakaan pilihan mereka termasuk Preact, Polymer, atau Vue, dan sekarang React bisa menjadi opsi yang didukung secara resmi juga.

Saya ingin mengucapkan terima kasih kepada semua orang yang telah berpartisipasi dalam diskusi sejauh ini, saya sangat menghargainya. Debat dan diskusi yang sengit dalam komentar di sini dan di Hacker News dan Reddit sangat bagus untuk semangat yang dibawa orang-orang dan kesempatan untuk belajar tentang begitu banyak sudut pandang yang berbeda; bahkan lebih baik Facebook mendengarkan.

→ https://ma.tt/2017/09/facebook-dropping-patent-clause/

@ahmadawais @m

Keputusan kami untuk menjauh dari React, berdasarkan sikap mereka sebelumnya, telah memicu banyak diskusi menarik di dunia WordPress. Khususnya dengan Gutenberg, mungkin ada pendekatan yang memungkinkan pengembang untuk menulis blok Gutenberg (Gutenblocks) di perpustakaan pilihan mereka termasuk Preact, Polymer, atau Vue, dan sekarang React bisa menjadi opsi yang didukung secara resmi juga.

Situasi itu akan tampak seperti kemenangan bagi semua orang. Mari kita tunggu dan lihat bagaimana ini benar-benar berhasil.

Tutup saja masalah ini sekarang .. ini hanya untuk melihat betapa berubahnya dunia ini .. sedih melihat orang tidak tinggal dengan kata-kata mereka.

[Sunting: dihapus karena pernyataan yang menyinggung]

Semoga berhasil untuk semua orang yang harus menggunakan Gutenberg dan kurva belajar yang berat dalam mempelajari Bereaksi dengannya.

Perdamaian.

👋 Saya pikir kita semua memiliki banyak diskusi di sini. Saya ingin berterima kasih kepada semua orang, yang cukup peduli untuk berbicara dan mengomentari masalah ini. IMHO sepertinya semua opsi yang kami miliki saat ini adalah opsi yang bagus.

Jika kita berakhir dengan API agnostik kerangka kerja yang lebih baik, seseorang akan dapat menggunakan Kerangka JS apa pun yang mereka inginkan di aplikasi mereka. Dengan Lisensi MIT, React memiliki posisi yang kuat untuk digunakan di intinya seperti pustaka lainnya dengan lisensi open source yang bagus (kompatibel dengan baca).

🎯 Jika Anda melakukan rooting untuk Kerangka JavaScript tertentu, atau telah membangun satu (tim inti), saya sarankan Anda membuat contoh aktual untuk pengembang WordPress sehingga orang dapat mulai bermain-main dengan gagasan untuk menggunakan kerangka kerja JavaScript pilihan Anda di aplikasi berbasis WordPress mereka. membangun.

Saya menutup tiket ini untuk saat ini. Dan berharap dapat berkontribusi lebih banyak untuk kesuksesan WordPress baik sebagai platform maupun sebagai komunitas. Mengharapkan hal yang sama dari semua orang di sini. Saya benar-benar percaya bahwa ini akan menjadi petualangan rollercoaster bagi siapa saja yang bekerja dengan perangkat lunak WordPress.

Beberapa waktu dari sekarang, kami mungkin akan menyempurnakan perangkat lunak untuk membantu mempermudah penggunanya (~ 30% dari situs internet) seperti beberapa tahun yang lalu. Saya rooting untuk WordPress di sini, seperti Anda semua!

Bersulang!

Tidak begitu jelas dari komentar Matts jika keputusan untuk menjauh dari React telah dibatalkan.

Pertama , lisensi sebenarnya yang akan digunakan Facebook belum dipublikasikan , jadi, berpura-pura semuanya sudah berakhir bukanlah langkah yang masuk akal.

Kedua, itu tidak membahas lisensi dua tingkat yang diikuti Facebook: React mungkin MIT, tetapi React Native akan menjadi + (dirahasiakan) Paten .

Lantas .. bagaimana dengan komponen yang dimiliki oleh keduanya?

Bagaimana dengan kode React Native yang digunakan dalam React? Apakah Fiber akan dibagi antara dua lisensi yang berbeda? Atau kode GraphQL menemukan jalan ke React?

Apa yang terjadi pada WordPress jika itu mengikuti rute React, dengan semua proyek Facebook terkait ini diterbitkan di bawah lisensi yang berbeda, dan kemudian Facebook memutuskan bahwa beberapa aspek dari React benar-benar tunduk pada, misalnya, React Native Patent Grant, atau Fiber Hibah Paten?

Serius, pikirkan baik-baik tentang ini. Mengapa mengambil risiko ketika ada alternatif yang lebih suka digunakan mayoritas, yang tidak memiliki masalah ini - Vue.

Saya tidak akan mempercayai perjanjian lisensi yang berubah seiring angin, alih-alih dipikirkan dengan benar. Pengacara Facebook bisa membalikkan keadaan ini begitu saja.

Tetap gunakan Open Source asli.

@PericlesSouza Lisensi akan persis seperti yang dibayangkan orang di sini dari deskripsi posting blog: lisensi MIT standar, tidak lebih. React tidak bergantung pada React Native. Potongan-potongan yang dibagikan oleh keduanya tinggal di proyek React, bukan di React Native. React dan dependensi yang dimiliki FB akan tersedia di bawah MIT segera setelah tim kami memiliki waktu untuk melakukan perubahan. Kami tidak merencanakan bisnis yang lucu.

@septianjoko_

Anda bekerja untuk Facebook. Jika Anda bukan pengacara yang berwenang untuk berbicara atas nama Facebook, tidak peduli apa yang Anda klaim. Tidak peduli kode apa yang Anda tulis. Maaf.

Lisensi "Membayangkan" tidak berlaku di pengadilan.

Misalnya, dapatkah Anda secara tegas menyatakan mengapa Facebook mengadopsi Hibah Paten, apa Patennya (atau tidak), atau mengapa mereka mengatakan bahwa mereka mengubahnya sekarang, tanpa mengatakan 'IANAL' (Saya Bukan Pengacara)?

Potongan-potongan yang dibagikan oleh keduanya tinggal di proyek React, bukan di React Native

Tapi bisakah Anda mengatakannya dengan jaminan hukum? Tidak?

React dan dependensi yang dimiliki FB akan tersedia di bawah MIT segera setelah tim kami memiliki waktu untuk melakukan perubahan

Bagian apa yang dihapus agar React dapat diterbitkan di bawah MIT? Dependensi _non-FB milik_ apa yang mungkin tidak sesuai dengan MIT yang sudah Anda gunakan ..? Akankah pengacara Facebook menjamin bahwa semuanya benar-benar sesuai dengan MIT? Berapa lama waktu yang dibutuhkan Apache Software Foundation untuk mensertifikasi ini?
.

Sepertinya saya benar untuk menyoroti bahwa kode dibagi antara dua proyek yang tampaknya akan memiliki lisensi dua tingkat.

Anda memutarbalikkan kata-kata saya. Kode yang dibagikan antara React dan React Native akan dilisensikan di bawah MIT. Semua yang Anda anggap sebagai Fiber akan dilisensikan di bawah MIT. React tidak akan menyertakan atau bergantung pada kode yang dilisensikan di bawah BSD + Patents atau hak paten lainnya yang sangat Anda benci. Kami tidak menghapus bagian dari React. Satu-satunya dependensi non-FB milik React yang saya ketahui adalah object-assign yang juga berada di bawah MIT.

Saya tidak menyarankan Anda mengambil kata-kata saya sebagai jaminan hukum. Kami berdua sadar bahwa komentar saya di sini tidak mengubah lisensi React sendiri. Anda dapat memilih untuk bersikap skeptis dan tidak harus mempercayai saya sekarang, tetapi dalam satu atau dua hari Anda akan melihat bahwa apa yang saya katakan di sini benar.

@septianjoko_

Saya tidak memutarbalikkan kata-kata Anda - dan saya menghormati pekerjaan yang Anda lakukan, dan kesiapan Anda untuk terlibat di sini.

Saya hanya mengatakan bahwa kecuali dan sampai kami mendapatkan komitmen hukum dari Facebook, oleh pejabat resmi perusahaan, diverifikasi oleh badan sumber terbuka eksternal, maka kami masih dalam posisi yang sama seperti saat kami memulai - tidak ada yang dapat memastikan bagaimana situasi hukum yang sebenarnya adalah, sebagaimana Anda setuju dengan menyatakan:

Saya tidak menyarankan Anda mengambil kata-kata saya sebagai jaminan hukum. Kami berdua sadar bahwa komentar saya di sini tidak mengubah lisensi React sendiri.

Dan:

Semua yang Anda anggap sebagai Fiber akan dilisensikan di bawah MIT.

Tidak masalah apa yang saya anggap sebagai Fiber, itu sepenuhnya tergantung pada apa yang didefinisikan oleh pengacara Facebook dan paten yang diajukan sebagai Fiber.

Mengapa React Native saat ini dimaksudkan untuk mendapatkan lisensi yang berbeda dari React, ketika kode tersebut dibagikan dengan React? Apakah itu tidak membuat (maafkan permainan kata) lisensi MIT tidak valid?

Saya juga mencatat bahwa Anda tidak menyebutkan GraphQL. Ada lagi yang terlewat?

Inti dari masalah lisensi React, adalah kurangnya kepastian hukum.

@septianjoko_

Saya mencatat suntingan Anda sebagai tanggapan atas poin saya:

React tidak akan menyertakan atau bergantung pada kode yang dilisensikan di bawah BSD + Patents atau hak paten lainnya yang sangat Anda benci. Kami tidak menghapus bagian dari React. Satu-satunya dependensi non-FB milik React yang saya ketahui adalah object-assign yang juga berada di bawah MIT.

Tapi Anda mengatakan Anda menghapus bagian dari React, dan akan memeriksa kode "dalam beberapa hari mendatang".

React dan dependensi yang dimiliki FB akan tersedia di bawah MIT segera setelah tim kami memiliki waktu untuk melakukan perubahan

Dan Anda lupa IANAL ... :-)

Oh, sebenarnya Anda mengatakannya dalam bentuk panjang:

Saya tidak menyarankan Anda mengambil kata-kata saya sebagai jaminan hukum. Kami berdua sadar bahwa komentar saya di sini tidak mengubah lisensi React sendiri.

Sekali lagi:

Inti dari masalah lisensi React, adalah kurangnya kepastian hukum.

Saya setuju dengan poin yang masih belum ada kepastian hukum. Tetapi secara pribadi saya yakin utas ini telah berjalan dengan sendirinya; paling baik untuk menandainya sebagai kontributor saja, dan menunggu hingga Lisensi sebenarnya diterbitkan, dan tim dapat membuat penilaian.

Berhenti berlangganan sekarang.

Tolong jangan membuang React, Facebook membuat keputusan mereka https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

@vinayakkulkarni Meskipun saya memahami bahwa saya memiliki hasrat terhadap sesuatu, itu bukanlah alasan untuk memberi komentar seperti yang Anda lakukan. Ruang publik (yang dikomentari GitHub), harus menjadi tempat yang aman bagi siapa saja. Analogi Anda menyinggung dan karenanya telah diedit. Di masa mendatang, harap pikirkan bahwa semua jenis kelamin, semua jenis orang menggunakan ruang ini dan bagaimana ucapan Anda dapat menyinggung perasaan mereka.

@sophiebits hanya sedikit catatan untuk mengucapkan terima kasih telah datang ke utas ini, itu dihargai.

Ini mungkin topik untuk utas baru, tetapi sayangnya lisensi MIT (bahkan yang standar) tidak menghapus masalah "ketidakpastian" dengan paten, yang menyebabkan keputusan WordPress sebelumnya.

Apakah lisensi MIT memberi Anda hak untuk menggunakan IP yang dipatenkan? Baca apa yang dikatakan pengacara tentang itu: Lisensi MIT, Baris demi Baris

- Frans Bouma (@FransBouma) 23 September 2017

MIT tampaknya tidak memberi Anda lisensi paten. Facebook memiliki paten di React, yang dikatakan memberi Anda lisensi saat ini. Dengan lisensi saat ini, setidaknya Anda tahu bahwa Anda diberikan lisensi apa pun yang ada, dan tahu persyaratan apa yang mencabutnya. Dengan MIT, Anda bahkan tidak mendapatkan lisensi.

Hibah paten berarti ada paten yang terlibat (atau apa yang diberikannya?). Kecuali tidak ada yang tahu apa hak patennya. Facebook tidak memberi tahu, bahkan ketika memberi mereka, dan tidak ketika mengumumkan pencabutan hibah.

Terlepas dari apa yang mungkin saya pribadi atau tim WordPress pikirkan tentang maksud ini, yang tampaknya masih ada adalah kebingungan seputar situasi hukum dari paten Facebook (namun tidak terdaftar) yang dimilikinya di React, yang siapa pun yang menggunakannya [[mungkin - atau- mungkin tidak]] perlu khawatir tentang pelanggaran, saat menggugat Facebook hari ini, atau hanya dengan menggunakan React setelah lisensi baru.

Sekali lagi, mungkin atau mungkin tidak, masalahnya adalah ketidakpastian, dan itulah yang saya sarankan tidak terselesaikan.

Sebagai pengingat, mayoritas yang menawarkan pendapat mereka di utas ini menginginkan solusi berbasis Vue.

Ada beberapa alasan untuk ini, tidak terbatas pada fakta bahwa Vue tidak memiliki kebingungan Lisensi (yang masih tetap dengan kebijakan lisensi dua tingkat Facebook):

1. Vue dirancang dari bawah ke atas untuk ditambahkan secara bertahap, dengan fungsionalitas pulau, memungkinkan peningkatan basis kode secara bertahap.

2. Selain itu, dan secara opsional, ini menyediakan solusi pengelolaan dan perutean yang didukung secara resmi.

3. Ini mendukung banyak prosesor untuk HTML, memberi pengembang pilihan bahasa template - HTML, JSX, Pug, dll, atau fungsi render.

4. Komponen file tunggal dan CSS tercakup (Stylus, SASS, SCSS, PostCSS, Komponen CSS) - dengan cara yang paling mudah. Cukup tambahkan atribut scoped ke deklarasi Style komponen Anda, dan selesai.

5. Dukungan untuk properti yang dihitung (dengan memoization) built-in (yaitu tanpa ketergantungan seperti MobX).

   6+. Performa unggul untuk Bereaksi, kurva pembelajaran yang jauh lebih rendah, adopsi yang lebih tinggi dalam komunitas PHP, lihat Laravel Mix misalnya - Anda dapat menggunakannya tanpa menggunakan Laravel itu sendiri. Atau cukup masukkan Vue melalui https://unpkg.com/vue dan mulai coding.

Vue lebih cocok untuk WordPress.

Bereaksi :

76.364 Github Stars
571 Masalah terbuka (!)
4325 Masalah tertutup
178 Permintaan Tarik Terbuka (!)
5,644 Permintaan Tarik Tertutup

Vue :

68, 246 bintang Github (lintasannya akan menyalip React oleh Natal)
62 Masalah terbuka (jauh lebih responsif terhadap perbaikan bug, menambahkan fitur yang diminta)
5,629 Masalah tertutup
17 Buka permintaan Tarik
863 Permintaan Tarik Tertutup

@Eligy

MIT tampaknya tidak memberi Anda lisensi paten. Facebook memiliki paten di React, yang dikatakan memberi Anda lisensi saat ini. Dengan lisensi saat ini, setidaknya Anda tahu bahwa Anda diberikan lisensi apa pun yang ada, dan tahu persyaratan apa yang mencabutnya. Dengan MIT, Anda bahkan tidak mendapatkan lisensi.

Hibah paten berarti ada paten yang terlibat (atau apa yang diberikannya?). Facebook tidak memberi tahu, bahkan ketika memberi mereka, dan tidak ketika mengumumkan pencabutan hibah.

Disitulah letak masalah dengan tidak-cukup-Open-Source dari sebuah perusahaan besar. Pada akhirnya, pengacara mereka akan menolak niat baik tim pengembangan apa pun, baik sekarang atau di masa depan.

Facebook membingkai lisensi + Paten mereka sebagai pertahanan agresif atas 'sesuatu atau apa pun', dan sekarang kami diminta untuk percaya bahwa 'sesuatu atau apa pun' yang sama tidak benar-benar ada untuk React, tetapi, _ masih ada_ untuk React Native dan GraphQL dll.

Dapatkah Automattic berjanji bahwa mereka akan menanggung beban sendiri dan menjalankan React, bercabang, mengembangkannya sendiri, ketika Facebook kembali mengubah lisensi dan pendapatnya tentang React?

Bagi saya, sepertinya Facebook memasang jebakan untuk WordPress. 25% dari semua situs web di dunia adalah tangkapan besar.

harap tandai utas ini sebagai _kontributor saja_ ASAP, akan sangat bagus untuk membaca hasil kontributor, bukan hanya FUD dan spekulasi, tanpa perlu berhenti berlangganan sepenuhnya. Terima kasih.

Pemangku kepentingan

@PericlesSouza mengutip bintang Github tidak berarti apa-apa. Dan bahwa masalah ini diburu-buru oleh orang-orang yang melontarkan klaim konyol, bukan berarti kita harus mengabaikan fakta: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue tidak lebih dari sekadar blip di radar. Mayoritas yang mengejutkan menggunakan React dan pasti juga tidak setuju dengan poin-poin Anda.

@PericlesSouza mengutip bintang Github tidak berarti apa-apa. Dan bahwa masalah ini diburu-buru oleh orang-orang yang melontarkan klaim konyol, bukan berarti kita harus mengabaikan fakta: https://npmcharts.com/compare/react , angular, @ angular / core , ember-cli, vue

Vue tidak lebih dari sekadar blip di radar. Mayoritas yang mengejutkan menggunakan React dan pasti juga tidak setuju dengan poin-poin Anda.

Statistik NPM? Maksud Anda statistik yang sama yang mereka akui menghitung setiap permintaan untuk memeriksa apakah Anda menggunakan versi terbaru atau tidak, atau melalui setiap ketergantungan, sebagai permintaan untuk mengunduh? (Mereka mengakui ini di blog mereka ketika orang-orang menertawakan klaim "miliaran paket sebulan" mereka).

Jika Anda ingin pergi ke rute itu, semua orang menggunakan jQuery.

Mungkin coba gambar untuk paket yang tidak memiliki bidang distorsi ketergantungan itu:

https://npmcharts.com/compare/vue-cli , create-react-app

Gambar yang sama sekali berbeda dengan yang Anda pilih untuk disajikan.

Atau bagaimana dengan penggunaan situs web:

https://w3techs.com/technologies/comparison/js-react , js-vuejs

Yang didukung oleh statistik BuiltWith:

Oh, dan saya akan meninggalkan gambar ini di sini - dari saat tim bertanya kepada Komunitas itu sendiri. Anda harus mendengarkan mereka daripada memperlakukan mereka dengan jijik.

@PericlesSouza Tidak masuk akal untuk membandingkan vue-cli dengan create-react-app karena ada alat build lain yang sangat populer untuk React seperti Next.js dan GatsbyJS .
Banyak pengembang React bahkan tidak menggunakan CLI dan sebaliknya menggunakan skrip build Webpack kustom mereka sendiri seperti yang dilakukan Gutenberg dan Calypso.

Kenyataannya adalah bahwa ekosistem React jauh lebih besar daripada milik Vue. Ambil contoh Material UI untuk Vue.js yang memiliki 4.339 bintang sedangkan Material UI untuk React memiliki 29.078 bintang.

Komponen kotak pilihan asli yang menyediakan fungsionalitas serupa dengan Select2 tanpa overhead jQuery: Vue select memiliki 1.348 bintang sedangkan pemilihan React memiliki 8.493 bintang.

@PericlesSouza , @drcmda , semua data ini dapat diperebutkan dengan banyak cara, bahkan statistik npm dengan cli, jika Anda menambahkan AngularCLI dan EmberCLI Anda akan melihat data yang sangat berbeda, yang tidak berarti apa-apa:

Sumber: https://npmcharts.com/compare/vue-cli , create-react-app, @ angular / cli , ember-cli

Sumber: https://w3techs.com/technologies/comparison/js-angularjs , js-react, js-vuejs

Sumber: https://insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-technology

Tetapi percakapan ini tidak boleh tentang kerangka kerja mana yang paling banyak digunakan, tetapi mana yang lebih baik untuk lingkungan Wordpress secara keseluruhan.

@PericlesSouza @willgm Aturan berlaku untuk keduanya. Keduanya dihitung dengan cara yang persis sama, cukup tidak jujur ​​untuk mengklaim bahwa itu tidak adil. Bergantung pada CLI opsional atau situs web sugestif yang menghitung "suka" dan "bintang" adalah sia-sia. Bahkan stackoverflow sangat subjektif dan saya bahkan belum pernah mendengar tentang situs "builtwith ..." sampai hari ini, dan statistik CLI, mencerminkan berapa banyak yang menggunakan CLI (mayoritas tidak).

Data dari sumber yang paling jelas dan penting, yang mencerminkan lingkungan produksi nyata dalam keadaan yang persis sama adalah satu statistik yang Anda tidak suka, saya mengerti, tidak berubah sebagaimana adanya.

Tetapi percakapan ini tidak boleh tentang kerangka kerja mana yang paling banyak digunakan, tetapi mana yang lebih baik untuk lingkungan Wordpress secara keseluruhan.

Dan saya rasa Anda tahu mana yang lebih cocok. Anda pikir 400.000 orang per hari yang mendapatkan React off npm semuanya salah. Vue dapat bersaing sendiri, tidak benar-benar membutuhkan massa yang bergegas ke pelacak masalah.

@PericlesSouza @willgm Aturan berlaku untuk keduanya. Keduanya dihitung dengan cara yang persis sama, cukup tidak jujur ​​untuk mengklaim bahwa itu tidak adil. Bergantung pada CLI opsional atau situs web sugestif yang menghitung "suka" dan "bintang" adalah sia-sia.

Nggak. React memiliki 16.800 paket dependen yang mengubah angka tersebut. NPM mengakui bahwa semua yang mereka hitung sebagai unduhan adalah kode hasil 200 saat memanggil URL, sebagai hasil dari pemeriksaan ketergantungan, atau bot, atau cermin, atau apa pun. Kebetulan, mereka juga mengatakan bahwa sebagian besar unduhan di China, di mana Vue sangat populer, berasal dari mirror, dan tidak dihitung.

Menilai dari penggunaan bahasa Anda - 'clinging', 'sugestive websites', 'sia-sia', Anda tidak memiliki argumen nyata tentang hal ini, sedangkan, seperti yang diminta oleh Tim, saya telah memposting hal-hal positif dari menggunakan Vue (lihat di atas ).

Counting Stars - orang lain melakukan itu saat menunjukkan kesuksesan React, namun Anda mengecam nilainya saat digunakan untuk menunjukkan popularitas Vue? Anda juga tidak menyebutkan jumlah masalah yang belum diselesaikan yang jauh lebih tinggi ( 571 ), dan jumlah permintaan tarik yang luar biasa ( 178 ) yang masih menunggu untuk React, yang jika dibandingkan dengan respons yang lebih tinggi dari komunitas Vue dalam perbaikan bug dan menambahkan fitur, merupakan alasan yang valid untuk mengkhawatirkan saat mengusulkan penggunaan React.

Yang membawa saya ke:

Menghitung Suka - yah, itulah inti dari utas ini, seperti yang dimulai oleh tim dan diminta oleh Komunitas - saya rasa Anda tidak menyukai hasilnya. Ini dia lagi, dan sangat meyakinkan:

Nggak. React memiliki 16.800 paket dependen yang mengubah angka tersebut.

@PericlesSouza Bagaimana Anda bisa sampai pada kesimpulan itu. Artinya apa artinya: 16.800 paket telah mendeklarasikan React sebagai dependensi mereka di package.json. Bukan bot, bukan China, ... paket. Vue memiliki sekitar 2580, yang berarti ia memiliki sistem eko ​​dan basis pengguna yang jauh lebih kecil. Mengapa kita bahkan memperdebatkan ini? Ini secara langsung tercermin oleh statistik penggunaan. Pembaruan, orang nyata atau bot, ini berlaku untuk kedua paket. Kecuali jika Anda berasumsi bahwa bot sengaja melewatkan Vue karena suatu alasan.

Untuk memilih satu paket dalam pelacak yang memperlakukan setiap paket sama tidak masuk akal. Di sisi lain, menghitung suka tidak lebih dari komunitas yang XY tahu di mana harus memilih.

@tokopedia

Saya pikir apa yang dia maksud adalah bahwa setiap kali Anda menginstal paket yang memiliki ketergantungan pada React, dan itu mengenai NPM untuk memeriksa versi dan ketergantungan, NPM menghitungnya sebagai download dari paket tersebut, bahkan jika tidak diunduh.

Jika itu yang dia maksud, maka dia benar; secara eksplisit dinyatakan oleh NPM bahwa mereka melakukan ini; mereka mendeskripsikan 'metodologi' mereka sebagai 'sengaja naif' (mereka juga menyebutkan bahwa bot dan mirror dapat membelokkan angka karena mereka tidak memiliki mekanisme untuk menentukan untuk apa sebuah permintaan, mereka hanya menghitungnya). Dan React memiliki lebih banyak paket dependen, oleh karena itu efek ini lebih terasa.

Adapun banyak paket dependen - ya, React adalah kerangka kerja yang lebih lama, ia memiliki lebih banyak, dan itu agak membutuhkannya. Saya mengembangkan dengan React dan Vue, dan dengan Vue Anda cenderung membutuhkan lebih sedikit paket tambahan, karena intinya cukup lengkap, dan Router resmi dan Vuex juga mengikuti filosofi ketergantungan rendah. Vue sendiri tidak bergantung pada paket apa pun, React bergantung pada beberapa paket. Mereka memiliki pendekatan yang berbeda dalam hal ini.

Contoh lain adalah bahwa orang cenderung menggunakan paket integrasi antara say Bootstrap dan React, atau menggunakan pustaka seperti komponen bergaya, nama kelas, dll. Dengan Vue Anda umumnya tidak perlu, meskipun proyek semacam itu juga ada. Saya menemukan Vue jauh lebih mudah untuk dikerjakan karena saya dapat memiliki CSS cakupan komponen di luar kotak tanpa pustaka atau konfigurasi tambahan, dan saya dapat menulis integrasi sederhana saya sendiri dengan kerangka kerja CSS sesuai kebutuhan, daripada mengimpor seluruh pustaka integrasi dan kemudian mencoba pohon -mengguncang 75% yang tidak saya butuhkan.

@PericlesSouza Anda melewatkan beberapa item yang cukup relevan dari posting 'Pro Vue' Anda:

Slot Bernama untuk memungkinkan komponen templat yang dapat digunakan kembali seperti Formulir standar, Input, Tata Letak, dll., Yang lebih fleksibel daripada penggunaan anak-anak di Reacts.

Komponen bersyarat dengan kemampuan opsional untuk status lokal Keep-Alive tanpa merusak komponen non-aktif.

Elemen HTML 'Is' adalah sintaks komponen Vue untuk template string, yang mencegah pengangkatan elemen HTML yang dirender yang menghasilkan HTML yang tidak valid.

Aliran data satu arah dengan props, tetapi dengan tambahan aliran 'emit' dan 'event bus' yang lebih disederhanakan untuk memberi tahu atau memperbarui saudara atau orang tua. Ini dapat berguna untuk pergaulan antara:

Beberapa contoh Vue di halaman, mengontrol wilayah tertentu. Teknik ini berguna untuk dasbor dinamis atau widget yang dapat dicolokkan, dan manajemen memori.

Komponen global dan lokal serta registrasi arahan kustom.

Filter Berantai selain properti yang dihitung.

Semua hal di atas adalah bagian dari pustaka inti Vue.

React adalah kerangka kerja yang bagus, dan saya senang menggunakannya, tetapi secara pribadi menurut saya Vue lebih cocok untuk kasus penggunaan yang diusulkan ini.

@bayu_joo

Ya, saya terburu-buru dan tidak punya waktu untuk membuat daftar lengkap keunggulan Vue.

Menarik bahwa Anda menyebutkan React memiliki dependensi karena saya perhatikan itu tergantung pada fbjs . Saya menambahkan beberapa penekanan pada bagian-bagian yang seharusnya memicu alarm jika orang-orang mempertimbangkan React, dengan strategi lisensi dua tingkat Facebook sambil berbagi kode di antara proyek-proyek berlisensi yang berbeda. Petunjuk segala sesuatu tentang itu mengkhawatirkan terutama ketika Anda melihat daftar proyek yang bergantung padanya, tetapi memiliki lisensi yang berbeda.

https://www.npmjs.com/package/fbjs

https://www.npmjs.com/browse/depended/fbjs

Tujuan

Untuk memudahkan Facebook berbagi dan menggunakan JavaScript kita sendiri.

Catatan: _Jika Anda menggunakan kode di sini dan Anda bukan juga proyek Facebook, bersiaplah untuk waktu yang buruk_. _Pustaka ini diterbitkan dengan mempertimbangkan kasus penggunaan kami dan tidak selalu dimaksudkan untuk dikonsumsi oleh publik yang lebih luas. Kami mungkin tidak akan menerima permintaan fitur Anda kecuali jika sesuai dengan kebutuhan kami.

571 Masalah terbuka (!)

Sekarang 338. (Saya menghabiskan beberapa hari untuk membersihkannya.)

Selama beberapa bulan terakhir, tim React sibuk mempersiapkan rilis React 16 baru yang sebagian besar kompatibel dengan versi sebelumnya. Ini adalah rilis terbesar kami, jadi kami tidak menanggapi pelacak masalah, jadi saya minta maaf. Ternyata, React 16 juga memecahkan banyak masalah tersebut. :-)

Saya ingin menunjukkan bahwa sebagian besar dari 338 masalah yang tersisa adalah permintaan fitur dan diskusi. Pencarian label bug memberi saya sekitar 60 masalah. Dan mengingat ekosistem React lebih besar dari Vue saat ini, tidak mengherankan jika orang menemukan lebih banyak kasus dan ketidakkonsistenan, dan memulai lebih banyak diskusi. Mereka juga mengharapkan React untuk mem-polyfill lebih banyak inkonsistensi browser, sehingga banyak bug terkait dengan cakupan yang hilang dari mereka. Selain itu, kami menyimpan dokumentasi di repositori yang sama, jadi sebagian besar masalah tersebut adalah tentang dokumen.

Saya harap ini memberi Anda wawasan tentang mengapa kami cenderung memiliki jumlah masalah yang lebih tinggi daripada Vue.

Menarik bahwa Anda menyebutkan React memiliki dependensi karena saya perhatikan itu tergantung pada fbjs. Saya menambahkan beberapa penekanan pada bagian-bagian yang seharusnya memicu alarm jika orang-orang mempertimbangkan React, dengan strategi lisensi dua tingkat Facebook sambil berbagi kode di antara proyek-proyek berlisensi yang berbeda. Petunjuk segala sesuatu tentang itu mengkhawatirkan terutama ketika Anda melihat daftar proyek yang bergantung padanya, tetapi memiliki lisensi yang berbeda.

Sayangnya ini FUD tidak berdasar, berhenti penuh. Saya tidak yakin apa motivasi Anda untuk menyebarkannya, tetapi React telah diberi lisensi kembali sebagai MIT, dan itu termasuk kode yang bergantung pada React (seperti fbjs). Tidak ada skema licik di sini.

Anda dapat melihat sendiri bahwa lisensi fbjs juga telah diubah menjadi MIT di https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 lima hari sebelum komentar Anda. Rilis React 16 yang keluar beberapa hari yang lalu tidak berisi satu byte non-MIT.

Fakta bahwa proyek lain bergantung pada fbjs tetapi memiliki lisensi yang berbeda sama sekali tidak relevan, sama seperti tidak relevannya kode aplikasi Anda mungkin bukan MIT tetapi bergantung pada Vue.

PS Saya pikir Vue hebat, dan saya tidak ingin memaksakan React pada siapa pun. Tetapi saya ingin memastikan bahwa kita mendasarkan diskusi ini pada fakta. :-) Kami selalu terbuka untuk kritik, dan saya yakin Vue dan React memiliki hal-hal untuk dipelajari dari satu sama lain.

Semua ini adalah pembicaraan yang menarik.

Saya harus bertanya - mengapa framework / library sama sekali? Seperti yang disebutkan sebelumnya, standar Komponen Web tampaknya menyediakan apa yang dibuat untuk disuplai oleh ReactJS, Vue, dan lainnya (karena standar tersebut tidak ada).

Anda dapat menggunakan pustaka negara seperti Redux dengan baik dengan komponen web. Mirip dengan pustaka perutean. SSR tidak begitu berkembang dengan Komponen Web, namun ada orang yang bekerja di sana juga. Sebagian nilai terbesar dari React adalah berbagai pustaka pendukung di sekitarnya - yang tidak selalu hilang dengan menggunakan platform.

Apa yang diberikan kerangka XXX kepada Anda atas Komponen Web platform?

Bicara yang mengasyikkan memang ...

Lisensi keempat untuk React, sejauh ini.

1. Awalnya Apache 2.0. Seharusnya baik-baik saja, bukan? Apa masalahnya?
2. Kemudian BSD + Paten. Tanpa mengungkapkan apa hak paten ada, atau tidak ada.
3. Kemudian sedikit perubahan, diduga untuk menyenangkan Google. Tanpa ada detail kenapa.
4. Sekarang MIT, dengan pemfaktoran ulang React yang tidak ditentukan, tetapi tidak untuk proyek yang terkait langsung, seperti React Native, GraphQL, dll ... dan ketergantungan bersama dengan deskripsi publik "Untuk memudahkan Facebook untuk berbagi dan menggunakan JavaScript kita sendiri. Terutama ini akan memungkinkan kami untuk mengirimkan kode tanpa terlalu mengkhawatirkan di mana kode tersebut berada "

Ternyata semua itu, sama sekali tidak perlu dikhawatirkan.

[edit dihapus oleh Tammie Lister: info pribadi seperti ini tidak dapat diterima]

@PericlesSouza Anda dapat membantah bahwa kami tidak boleh dipercaya karena lisensinya membingungkan sebelumnya. Itu valid jika itu argumen Anda. Tetapi lisensi seharusnya tidak membingungkan sekarang.

Bereaksi adalah MIT.
Ketergantungannya fbjs adalah MIT.
Kode yang dibagikan oleh React dan React Native (yang telah dan terus ada di repo React) adalah MIT.
React, termasuk semua dependensinya, adalah MIT.
Buat Aplikasi React tidak perlu menggunakan React, tapi juga MIT.
Relay dan graphql-js tidak diperlukan untuk menggunakan React, tetapi mereka juga MIT.

Kami merilis React 16.0 dengan lisensi baru. Sangat mudah untuk memverifikasi ini.
Kami juga merilis versi baru React 15.x dengan lisensi MIT sebagai 15.6.2.
Kami berencana untuk merilis semua versi React yang akan datang di bawah lisensi MIT juga.

Selain itu, karyawan Facebook lain di utas ini mengakui bahwa React (MIT untuk 16? Untuk apa <16? 17+? Lebih baik perhatikan package.json itu dengan hati-hati) dan kode saham React Native, yang memerlukan refactoring (kemudian mengedit komentarnya) untuk menghapus pernyataan itu, setelah saya mengutipnya).

Saya insinyur itu. (Nya.)

Anda berkomentar https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418, lalu saya membalas https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521.

Inilah konten asli dari dua komentar kami, seperti yang tercatat di klien email saya:

Ini kontennya saat ini:

Setelah saya memberikan komentar saya, Anda mengedit komentar Anda menjadi lebih panjang, termasuk pertanyaan tambahan:

Bagian apa yang dihapus agar React dapat diterbitkan di bawah MIT?

yang tidak ada dalam komentar asli Anda. Jadi sebagai tanggapan atas suntingan Anda, saya mengedit komentar saya untuk menambahkan:

Kami tidak menghapus bagian dari React. Satu-satunya dependensi non-FB milik React yang saya ketahui adalah object-assign yang juga berada di bawah MIT.

Yang kemudian Anda anggap tepat untuk memanggil saya di komentar berikut. Beraninya saya mengedit komentar saya untuk menjawab pertanyaan yang Anda tambahkan dalam suntingan Anda. Saya tidak menghapus atau mengedit klaim apa pun tentang kode berbagi React dan React Native.

-

Tolong hentikan gaslighting saya. Ini melelahkan.

@youknowriad Apakah Anda berbaik hati mengunci utas ini? Saya tidak bisa membayangkan ada diskusi yang lebih produktif terjadi di sini.

Jika ada orang lain di sini yang masih khawatir tentang lisensi, silakan DM saya dan saya akan melakukan yang terbaik untuk mengklarifikasi.

Yang kemudian Anda anggap tepat untuk memanggil saya di komentar berikut. Beraninya saya mengedit komentar saya untuk menjawab pertanyaan yang Anda tambahkan dalam suntingan Anda. Saya tidak menghapus atau mengedit klaim apa pun tentang kode berbagi React dan React Native.

Jelas saya menanggapi suntingan Anda, apakah itu masalah Anda?

Tidak perlu gaslighting, cukup keterbukaan dan konsistensi dari Facebook, tim pengembangan React, dan perizinan, dan seperti yang ditunjukkan oleh empat model lisensi di Reacts yang waktu hidupnya relatif singkat, dan posting Anda (saat ini), sayangnya kurang.

Secara singkat mengesampingkan perizinan: Sekali lagi, apa yang React sediakan hari ini yang diperoleh di atas dan di luar Komponen Web? Dengan asumsi Anda masih akan menggunakan pilihan perpustakaan pendukung di keduanya (yaitu Redux).

Dengan Komponen Web, WordPress dapat membuat banyak elemen daripada yang dapat digunakan di berbagai kerangka kerja / pustaka front-end. Ini akan memungkinkan pengguna akhir dengan React, Vue, Angular, atau front end apa pun yang mereka gunakan untuk "memasukkan" komponen WordPress.

@sophiebits Tidak yakin versi posting Anda yang akan ditanggapi sekarang, jadi saya akan menunggu, dan melihat apa yang akhirnya terjadi. Ini benar-benar situasi yang sangat mirip dengan React.

@ Brian-Mcbride

Anda membuat poin yang bagus, dan saya percaya itu dimunculkan sebelumnya di utas - "mengapa tidak menggunakan vanilla javascript", berbasis standar, sepenuhnya sesuai.

Hmm.

Remove references to PATENTS that crept in #11091
Merged  sophiebits  merged 1 commit into facebook:master from sophiebits:nopatentsagain a day ago

https://github.com/facebook/react/pull/11091

Seperti yang saya katakan, berhati-hatilah dengan kontrol versi Anda jika Anda menggunakan React.

Ya, kami secara tidak sengaja melakukan tiga file dengan header yang salah, dari permintaan pull yang dibuka sebelum lisensi diubah. Tidak ada yang dalam versi rilis (juga tidak mungkin - satu adalah tes unit, dua adalah bagian dari situs web).

Terjadi kesalahan. Kami memperbaikinya ketika kami mengetahuinya dan saya menambahkan skrip ke CI kami untuk memverifikasi di masa mendatang bahwa tidak ada lagi referensi yang tidak disengaja yang ditambahkan. Anda bisa melihatnya di komit itu.

Satu hal tambahan yang menurut saya harus dipertimbangkan oleh proyek perangkat lunak bebas - Facebook mendapat manfaat dari penggunaan React.

Tetapi nilai-nilai Facebook umumnya tidak sejalan dengan gerakan perangkat lunak Bebas - mulai dari manipulasi pengguna yang tidak etis hingga serangan terhadap Netralitas Net ("Dasar-Dasar Gratis"), ketidakmampuan untuk menghapus data, ketidakmampuan untuk memblokir pengumpulan data, penyensoran, taman bertembok , ruang gema, dan banyak lagi.

[Facebook] seperti ketika saudara laki-laki saya biasa membuat saya memukul diri saya sendiri dan bertanya, "mengapa kamu memukul diri sendiri?" Lalu dia akan memberi tahu ibuku bahwa itu bukan salahnya.

Karena saya telah menonton Facebook selama bertahun-tahun, saya semakin mendekati kesimpulan bahwa saya tidak lagi ingin mendukung perusahaan itu dengan cara apa pun, jadi saya pribadi tidak menggunakan perangkat lunak FB setiap kali ada alternatif.

Saya membaca sebuah buku di React dan itu tampak hebat dari perspektif pemrograman - tetapi alternatifnya juga bagus, dan mereka tidak datang dengan beban mendukung Facebook.

Menurut saya, proyek perangkat lunak bebas harus selalu memilih pustaka perangkat lunak bebas yang independen setiap kali tersedia. Ada banyak alternatif hebat untuk WordPress, termasuk Vue, komponen web, Ember, dan Mithril. Vue memiliki dukungan besar dalam komunitas PHP dan tidak memiliki masalah etika yang menyertainya, jadi sepertinya itu akan cocok. Jika hanya untuk dasbor, mungkin ada baiknya untuk melihat sesuatu yang lebih menarik daripada JavaScript: Elm .

Ini tidak boleh tentang apa yang sedang tren atau keren saat ini, tetapi harus tentang apa yang memberikan kebebasan teknologi paling banyak kepada generasi berikutnya - secara langsung atau tidak langsung.

Hanya pemikiran lain untuk dipertimbangkan ...

Terima kasih untuk semua orang yang menyuarakan pendapatnya saat mencoba melakukan percakapan yang saling menghormati. Saya juga ingin menambahkan ucapan terima kasih khusus kepada @sophiebits , @gaearon , @ blake-newman, dan semua orang yang mewakili proyek yang dengan ramah meluangkan waktu untuk menjawab pertanyaan. Pengetahuan Anda sangat dihargai, dan selalu diterima.

Percakapan tersebut telah beralih ke pertemuan JavaScript di saluran Slack # core-js, ada ringkasan yang bagus di sini . Jika Anda tertarik untuk berpartisipasi dalam diskusi ini, kami mengundang Anda untuk bergabung dengan kami di sana. Alternatifnya, kami memiliki dua pendekatan untuk interoperabilitas yang dapat menggunakan kontribusi, pengujian, dan umpan balik: # 2463 dan # 2791.

Dan dengan itu, utas ini telah berjalan dengan sendirinya. Kami mengunci masalah ini, tetapi kami mendorong Anda untuk melanjutkan percakapan di tempat-tempat yang disebutkan di atas.

Untaian ini menghasilkan beberapa diskusi yang bagus, tetapi beberapa di antaranya menunjukkan perilaku yang tidak dapat diterima dan telah diedit. Penting untuk diingat bahwa https://wordpress.org/about/etiquette/ berlaku untuk semua proyek WordPress dan kami tidak akan mentolerir pelanggaran atau mereka yang melakukannya. Terima kasih, semuanya, yang telah berkontribusi dalam percakapan dengan penuh perhatian dan hormat.