Gutenberg: اختيار إطار عمل JavaScript لـ Gutenberg (~ WordPress)

تصويتي مع VueJS

اخترت VueJS

تتمتع Vue بمجتمع رائع ويجب أن تكون الخيار للأمام.

الزاوي شبيبة

سأصوت لصالح VueJS. كما هو موضح أعلاه ، فهي صديقة للمبتدئين وتستخدم بنجاح مع Laravel. هذا يجعلها الخيار الأمثل.

سأصوت أيضًا لصالح Vue JS

يرجى ملاحظة أن مجرد الصراخ "أنا أفضل Vue" أو "أريد XY" لا يساعد حقًا في اتخاذ أي قرار هنا. إذا كنت تريد التصويت ، فإنني أقترح استخدام ردود فعل الرموز التعبيرية أو شيء من هذا القبيل بدلاً من تشويش سلسلة محادثات يمكن أن تعمل كمكان لتوثيق النتائج عند تقييم أطر عمل مختلفة.

سأذهب مع Vue. من الأسهل التعلم والتكيف. بالإضافة إلى أنها أقل إثارة للجدل من Preact.

بالنسبة لمسألة "تبعية الشخص الرئيسي" التي تظهر من وقت لآخر ، أليس هذا هو كل مكون إضافي لميزة WordPress أو تقنية غير معروفة؟ قام Koop ببناء التعامل مع الوسائط القديمة ، وقام Weston بالعديد من أعمال Customizer ، ويعمل Matías وعدد قليل من الآخرين على Gutenberg ، وكان كل تغيير رئيسي تقريبًا في WordPress حدث في السنوات العديدة الماضية لديه مجموعة صغيرة من الأشخاص الذين يعملون عليه أو فهمه.

يمكن أن أنظر إلى هذا بطريقة خاطئة ولكن "تبعية الشخص الرئيسي" لأي خيار تبدو وكأنها رنجة حمراء. مع التبني ، يتم القضاء على تبعية الشخص الرئيسي تمامًا. كان WordPress في يوم من الأيام مشروع تبعية لشخص (أشخاص) رئيسي (مايك ومات) أيضًا. أعتقد أن هذه حجة ضعيفة لتجنب التبني.

مرة أخرى ، قد أفكر في هذا الخطأ تمامًا ، لكنه خيط فكري مشترك أراه يظهر من وقت لآخر ولا أفهم أهميته على ما يبدو.

للإضافة إلى تعليق swissspidy ، فإن إظهار بدلاً من الإخبار شيء يمكن أن يساعد أيضًا. إذا كان الناس يشعرون بقوة تجاه الاستبدال ، فقم بإظهار التغيير وكيف سيبدو الرمز في الفرع (مثلما يفعل # 2734 لـ Preact). بغض النظر عن القرار النهائي ، سيكون جوتنبرج أفضل حالًا في الاستكشاف بدلاً من تشويش سلسلة المناقشة.

سأصوت لصالح VueJS! إنه إلى حد بعيد أسهل طريقة للتكيف من قبل المجتمع.

أعتقد أن مكونات الويب (بدون بوليمر ، ولكن مع html مضاءة أو ما شابه ذلك إذا كانت هناك حاجة إلى DOM ظاهري) يجب النظر فيها بجدية. استخدام النظام الأساسي والمعايير أفضل من أي مكتبة أو إطار عمل! يصنع بنية مكونات قوية وآمنة في المستقبل ، والتي يمكن تشغيلها بشكل طبيعي مع جميع الأطر. (Vue ، Angular ، React - إلى درجة مختلفة حاليًا على الرغم من: https://custom-elements-everywhere.com/)

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

يسعدني مساعدة هذا المشروع في تجربة Vue أو مكون الويب إذا لزم الأمر.

تحقق أيضًا من PR # 2463 لـ Gutenberg _ "إمكانية التشغيل البيني للكتلة الحيادية (Vanilla، Vue)" _

أقترح الميل نحو Vue.js لعدة أسباب.

1. سجل حافل في إطار عمل PHP Laravel.
2. يبدو أنه من السهل التقاطها وتبنيها حتى يتمكن المزيد من الأشخاص من المساهمة.
3. إذا كنا نبتعد عن React ، فلنجعلها تحولًا واضحًا ومحددًا بعيدًا عنها (يبدو استخدام Preact وكأننا نتشبث به (React) بمعنى ما).

مجرد رأيي ولكن يبدو أنه الخيار الأفضل ويبدو أن العديد من الأشخاص الآخرين يفضلون Vue بالإضافة إلى أنه شيء يجب مراعاته على أي حال.

يبدو أن Vue تتمتع بزخم أكبر ودعم مجتمعي أفضل من Preact. إنه يحل المزيد من المشاكل (لأنه يأتي مع إدارة الدولة) وله منحنى تعليمي ألطف. الوثائق _ ممتازة_.

ما يقلقني مع Preact هو أنه يشبه إلى حد كبير أن تشعر React بالأمان القانوني (قد تغطي براءات اختراع React Preact) ، وعلى عكس React أن تكون منفذًا بسيطًا (هناك اختلافات كافية لكسر المكتبات المساعدة والمكونات الإضافية وما إلى ذلك).

Vue على طول الطريق حبيبي !!

• [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/)

نجوم جيثب -> هنا
سأكون سعيدًا للغاية لمطور WordPress إذا كان Vue.js 🖖

طورت Vue مجتمعًا رائعًا بمرور الوقت بالإضافة إلى تحديثات / ترقيات منتظمة لإطار العمل.

ملاحظة. انضم إلى https://chat.vuejs.org للحصول على تجربة مجتمعية رائعة .. بعض مطوري dopeass حقًا هناك :)

jbreckmckye لا أقصد إخراج المحادثة عن مسارها ، لكن هل تفهم ما هو بند براءة الاختراع؟ يتعلق الأمر بحماية facebook من دعاوى براءات الاختراع من الشركات الأخرى. على سبيل المثال ، لنفترض أن شركتي تصنع ثلاجات ذكية ونستخدم التفاعل في واجهة المستخدم. لنفترض أن لدينا براءة اختراع في هذا الشأن ، ثم بدأ FB في انتهاك براءة الاختراع تلك ... إذا رفعنا دعوى قضائية ، فلن نتمكن من استخدام رد الفعل.

لا علاقة له ببراءات الاختراع في رد الفعل (وهو ما لست متأكدًا من أن facebook لديه ... وإلا فسيتم رفع دعوى ضد أي شخص آخر لديه إطار عمل مشابه الآن)

بصفتي عضوًا أساسيًا في Vue.js ، أود معالجة مشكلة عامل الحافلة. نحن نعلم أن هذه نقطة أثيرت كثيرًا في الوقت الحالي ، ونعمل الآن على اتخاذ تدابير لمعالجة بعض المخاوف.

1) Vue.js org account for npm ، حتى نتمكن من النشر كفريق أسهل
2) إدارة التفاصيل داخليًا للحفاظ على تشغيل الأشياء (مواقع الويب ، إلخ)
3) بدء العمل الجماعي المفتوح لإغراء المساهمين ودعم المجتمع المتنامي. https://medium.com/the-vue-point/vue-is-now-on-opencollective-1ef89ca1334b
4) لقد نما نظام Vue البيئي بسرعة ، ويأتي المزيد والمزيد من مساهمات المستودعات الأساسية من المجتمع نفسه. https://www.youtube.com/watch؟v=993X1kiisFE
5) عند النظر إلى مستودعات Vue الرسمية ، يمكنك أن ترى أن الكثير منها يتم صيانته الآن بشكل كبير من قبل أعضاء الفريق الأساسي الآخرين أكثر من إيفان

ينمو موقع Vue.js بشكل عام بسرعة وقد انخفض "عامل الناقل" بشكل كبير. كما تلاحظ philiparthurmoore ، سيكون لإيفان دائمًا مشاركة كبيرة وهذا شيء جيد.

يبدو أن هناك الكثير من محبي VueJS هنا. هل قام أي شخص بالفعل بترحيل قاعدة بيانات كبيرة من React إلى Vue؟ ما هو شكل مسار الهجرة؟

مما يمكنني رؤيته ، يبدو Preact خيارًا أكثر واقعية نظرًا لأنه متوافق مع React. في حين أن الانتقال إلى Vue سيتطلب إعادة كتابة أكثر شمولاً.

patrickgalbraith هذا في الواقع هو السبب الخاطئ للنظر في Preact. يجب الحكم عليها بناءً على مزاياها وليس لأنه من الأسهل الانتقال إليها. يمكنني رؤية المشكلات التالية مع Preact

• مجتمع أصغر مقارنة بـ VueJS
• روائح الكود - قد يؤدي الانتقال إلى مكتبة مشابهة جدًا إلى إجبار الممارسات السيئة (للسبب الواضح لكونها المسار الأسرع)
• يشبه التمسك بـ Preact الالتصاق بـ React على أي حال (اقرأها في مؤشر ترابط)

لم أستخدم سوى Preact بطريقة محدودة ، لذلك ، هذا ما أعتقده تمامًا.

@ blake-newman شكرًا على مرورك وتوضيح ذلك. 💯

يجب الحكم عليها بناءً على مزاياها وليس لأنه من الأسهل الانتقال إليها.

نعم. هذا قرار طويل المدى.

patrickgalbraith إذا كان المشروع بأكمله قد اكتمل ،

نظرًا لأن المشروع لا يزال في مراحله الأولى ، مثل ahmadawais ،

تمتلك Vue و React و Preact أيضًا نماذج متشابهة جدًا. يمكنك التبديل بسهولة بين الاثنين ، وستكون هناك اختلافات.

هناك أيضًا أدوات يمكن أن تساعد في سلام الهجرة ، على الرغم من أنها ربما لا تكون عملية تمامًا. https://github.com/SmallComfort/react-vue

على الرغم من أن هذا لا يقارن بين الأدوات نفسها ، إلا أن هذه المقالة تثير نقاطًا رائعة يجب مراعاتها. https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

@ blake-newman هل هي حقًا المراحل المبكرة فقط على الرغم من اعتبارها أكثر من 6 أشهر في التطوير؟ ضع في اعتبارك أيضًا أن كاليبسو يبلغ من العمر أكثر من عامين أيضًا.

على أي حال ، أنا متأكد من أنها لن تكون مشكلة نظرًا لما قلته من أنه من السهل التبديل بين React و Vue ، فأنا أتطلع إلى رؤية طلب السحب الخاص بها.

يبدو الاستنسل واعدًا أيضًا.

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

رأيي هو أن هاتين النقطتين تشكلان حجة قوية لـ Vue:

• المبتدئين ودية و ..
• قدر هائل من دعم المجتمع

كلاهما ، في رأيي ، هما من الركائز الأساسية لمشروع WordPress.

قد أكون وحدي ، لكنني كنت أشاهد Evan Patreon عن كثب خلال الأشهر الستة الماضية أو نحو ذلك ، وقرأ أنه إذا لم يتمكن من الحصول على تمويل من خلاله ، فسيحتاج إلى مزيد من العمل.

إنها مخاطرة حقيقية عندما يكون تمويل المشروع منخفضًا ويكون مكتوبًا بشكل أساسي بواسطة شخص واحد (منذ أقل من ستة أشهر). في الواقع ، انخفضت أرقام Patreon الخاصة به مؤخرًا. إذا قال الرجل الرئيسي إنه قد لا يكون قادرًا على العمل عليها إذا لم تكن الموارد المالية مصطفة ، فإن الموارد المالية تشكل مخاطرة حقيقية للغاية. يعد اختيار إطار عمل مشروع كبير وطويل الأجل يعتمد على ما إذا كان أحد المطورين (الرائع) يمكنه دفع إيجار SF أمرًا كبيرًا.

بالطبع يمكن دعم Vue بسخاء من قبل الشركات الأخرى ولكن من الصعب معرفة ذلك.

لا يضمن تبني المجتمع طول عمر الإطار أيضًا ، يا رفاق. إذا لم تكن قد لاحظت ، فإن أطر العمل "تموت" طوال الوقت.

ومع ذلك ، فقد تأثرت بأن عضوًا من فريق Vue الأساسي ظهر بالفعل لمعالجة مشكلة المساهم الوحيد / عامل الناقل ، بالاسم حتى ، وقدم بعض الأسباب التي تجعل مشكلة مطور واحد قد تكون أقل مشكلة. لكنها كانت مشكلة حقيقية في الماضي القريب.

أصوت لصالح Vue

• واجهة برمجة تطبيقات بسيطة / يمكنك تعلم أهم الأشياء الأساسية في أقل من أسبوع
• تنفيذ تدفق بسيط عبر vuex
• نتائج سريعة: P
• المجتمع المتنامي
• معهد ماساتشوستس للتكنولوجيا

تصويت آخر لصالح Vue ، لجميع الأسباب المذكورة أعلاه. اعتذاري لأي شخص مع تفعيل إشعارات البريد!

@ michaelbdavidson7 ، سيحصل Vue في النهاية على مدخلات إيفان وكانت حملة Patreon تهدف إلى دعمه للقيام بمزيد من أعمال Vue الرائعة. لا يحصل على ما يكفي من Patreon ويتولى أعمالًا أخرى لا أعتقد أنها تعرض Vue للخطر. كما اقترح @ blake-newman (أحد المساهمين الأساسيين في Vue) (وإيفان نفسه قبل شهرين) ، لم تعد Vue تعتمد على شخص واحد فقط. بقدر ما لا يعتمد WordPress على شخص واحد. لدينا مات ، نعم ، ولكن يمكن أن يستمر WordPress في بعض التجسد بدون مات (آسف مات ؛)). نفس الشيء ينطبق على Vue (آسف إيفان ؛)).
ahmadawais الذي أشعر أيضًا أنه ليس دقيقًا فيما يتعلق بـ "تبعية الشخص الأساسي".

إذا تم تحقيق هذا الهدف ، يمكنني قضاء وقت أقل في التفكير في قنوات تحقيق الدخل الخاصة (على سبيل المثال ، الحصول على عقود الدعم / الاستشارات) والعمل بدلاً من ذلك على المحتوى الذي يفيد مجتمع Vue بأكمله ...

^ لم يتم تحقيق هذا الهدف ولم يكن قريبًا. بافتراض أنه قصد ما قاله ، فربما لا يزال يفكر في التعاقد ، وإذا تغير ذلك ، فيجب اعتباره تطورًا حديثًا جدًا. لا يزال هناك حتى الآن. إذا كان الشخص الرئيسي يتعاقد لدفع الإيجار ، فهناك خطر أنه قد لا يستمر في العمل على إطار العمل ، وإذا تغير ذلك ، فقد تغير مؤخرًا.

جميعكم يا رفاق مجرد صراخ الأطر بالاسم لم تتعلم أي شيء على مدى السنوات القليلة الماضية لول.

@ michaelbdavidson7 تحقق الهدف لدعم إيفان بالعمل عليه بدوام كامل. الهدف الإضافي هو المساعدة في دعم المجتمع بشكل أكبر وجزئيًا. وهكذا كانت ولادة الحملة الجماعية المفتوحة التي تهدف لغرض وحيد هو دعم المجتمع.

سأشير أيضًا إلى أن حملة Patreon ليست المصدر الوحيد للدخل من خلال المساهمات ، وللأسف فإن Patreon غير مناسب لكل شركة ترعاها. وبالتالي يتم دفع بعض المساهمات وفواتيرها بشكل منفصل.

سبب انخفاض الرقم هو أن أحد الرعاة كان من الصين ، وهناك حد للمبلغ المالي الذي يمكن إنفاقه من الصين في عام. هذا مؤقت فقط ونأمل أن يعود إلى الدعم.

قنوات الدخل الأخرى التي يحصل عليها إيفان من خلال ورش العمل ، ليست مفيدة للمجتمع فحسب ، بل له أيضًا. بهذه الطريقة يمكنه الحصول على عرض مباشر لدعم تعلم كيفية استخدام المكتبة. لذا فهي في الواقع ليست سيئة كما تبدو.

Vue مستدام ، وأنا لا أتحدث نيابة عن Evan ، لكنني متأكد من أنه سعيد جدًا بالوضع الحالي للشؤون المالية.

الشيء الوحيد الذي أقدره في React هو توثيق إمكانية الوصول . أعتقد أن هذا شيء يجب أن تكون على دراية به ومراعاته عند التفكير في أطر عمل جديدة. هناك مبادئ إمكانية الوصول مذكورة هنا والتي تنطبق على أي تطبيق ويب مكتوب بشكل دفاعي ، ولكن وجود بعض الوثائق الخاصة بإطار العمل قد يكون مفيدًا.

Vue.js لديه مشكلة مفتوحة تتعلق بإمكانية الوصول . نظرة سريعة على Preact وأنا لا أرى الكثير ؛ هل من الآمن افتراض أن التوثيق من React ينطبق؟

في النهاية ، سيكون من الرائع أن يكون لديك إطار عمل يجعل الاختبار البرمجي لـ a11y بسيطًا وتلقائيًا حتى نتمكن من التخلص من غالبية الأخطاء والتحذيرات.

إذا كنت تريد الانتقال السهل فقط بسبب الترخيص ، فإن أحد الخيارات التي يمكنك التفكير فيها هو InfernoJS. https://github.com/infernojs/inferno فإنه يوفر نفس واجهة برمجة التطبيقات مع مساحة أصغر ووقت تشغيل أسرع. مرخص لها MIT. أنا أحد المشرفين على الجحيم ويمكنني المساعدة في عملية الانتقال.

Havunen شكرا على

للسياق ، تم توظيف مؤلف Inferno بواسطة Facebook

أصوت لصالح markoJS http://markojs.com/

يستخدم غوتنبرغ بعض جديدة تتفاعل 16 ميزات أي البوابات وربما شظايا ، أن كلا من جحيم وPreact لا تدعم بحيث يمكن أن تؤخذ في الاعتبار عند الحديث عن رد فعل مثل يبس إذا كان استخدام هذه الميزات حاسمة لغوتنبرغ.

أقترح DIO 8 غالبًا لأنه أقرب شيء إلى React 16 في هذه المرحلة من حيث API.

ومع ذلك ، قد تكون تجربة فضول جيدة لإعداد Gutenberg للتسمية المستعارة لـ React-like libs المذكورة ومعرفة ما إذا كانت تعمل دون أي تغييرات / مشاكل لأي شخص يرغب.

لست متأكدًا مما إذا كانت متطابقة تمامًا ، ولكن بالنسبة للبوابات ، هناك بوابة vue تم تطويرها بواسطة LinusBorg ، أحد أعضاء فريق vue core :)

youknowriad تم تعييني بواسطة Facebook. Havunen والفريق وراء Inferno يقومون بعمل رائع بدوني. العمل الذي يقومون به على Inferno رائع والمشروع يستحق التحقق من Inferno إذا سنحت لك فرصة :)

أنا أحد مؤلفي Marko.js وأود طرح Marko.js في الحلبة للنظر فيها. لقد تواصل معنا عدد من أعضاء مجتمعنا وأبلغونا بمشكلة GitHub هذه. Marko.js لديه ترخيص MIT مفتوح المصدر سهل الاستخدام ويتم استخدامه لبناء موقع eBay.com ولديه مجتمع قوي ومتزايد. إنه يجلب عددًا من الأفكار الجيدة من React و Vue ، لكننا بذلنا الكثير من الجهد لجعل الأمور أبسط وأسرع (من خلال تحسينات وقت الترجمة) وقمنا بإزالة النموذج المعياري حيثما أمكننا. أردت فقط إبراز بعض الميزات أدناه:

مكونات واجهة المستخدم

نموذج مكوِّن ماركو مشابه جدًا من الناحية المفاهيمية لنموذج React (الإدخال ، الحالة ، ربط الحدث ، أحداث دورة الحياة ، عرض DOM الافتراضي ، اختلاف / تصحيح DOM ، إلخ). لن يتطلب الانتقال في كاليبسو الكثير من النفقات المعرفية. يدعم Marko أيضًا مكونات واجهة المستخدم أحادية الملف. إليك ما يبدو عليه مكون 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>

بناء الجملة

لا يستخدم Marko JSX ، ولكنه يستخدم مجموعة شاملة من HTML تدعم تعبيرات JS. إنه مشابه جدًا لـ HTML ، ولكنه لا يقتصر على HTML تمامًا كما هو الحال في Vue. هذا يعطي صيغة أجمل لأشياء مثل الحلقات والشرطية ويجعل الأمر أكثر وضوحًا حيث يتم استخدام التعبيرات مقابل سلسلة HTML القياسية. نشعر أن قوالب Marko.js سهلة القراءة للغاية ويمكن صيانتها (يدعم Marko أيضًا صياغة موجزة قائمة على المسافة البادئة)

التقديم من جانب الخادم

لا أعرف مدى أهمية ذلك بالنسبة إلى WordPress ، لكن Marko يدعم أيضًا العرض عالي الأداء من جانب الخادم ضمن Node.js مع دعم العرض غير المتزامن والمتدفق.

قراءة متعمقة:

• ماركو مقابل رياكت
• تبادل إطلاق النار من جانب الخادم مع Marko و Preact و Rax و React و Vue
• لماذا ماركو سريع؟
• 10 ميزات ماركو الرائعة
• Meetup: بناء واجهة المستخدم - مقارنة بين React و Vue و Marko (من صانع Marko) - فيديو | الشرائح

أصوت لماركو !! 🙂

إذا رغب أي شخص من فريق WordPress (ahmadawais؟m؟swissspidy؟) في إجراء محادثة سريعة للإجابة على أي أسئلة حول Marko ، فنحن ، فريق Marko ، سنكون سعداء للقيام بذلك. : call_me_hand: 😸

لقد علقت على هذا في مدونة m ، لكنني أردت نشره هنا بشكل أكثر عمومية:

أوصي بنظام Ember البيئي بما في ذلك Ember و Glimmer.js.
بالنسبة لمكونات الويب الأصغر مثل انخفاض المحررين وسلوكيات المحتوى الأخرى ، يوفر Glimmer تجربة رائعة ويخلق انخفاضًا في مكونات الويب التي يمكن أن تعمل خارج إطار العمل.

بالنسبة للمشاريع الأكبر مثل Guttenberg و Calypso حيث يتم تشغيل التوجيه وإدارة الحالة المعقدة والتحكم في الوصول وإدارة المحتوى والمزيد: توفر Ember أفضل مجموعة أدوات ونظام بيئي
مع مجموعة كبيرة من المساهمين: تساعد أنماط مجموعة Ember والوظائف الإضافية ونظام الإنشاء في الحفاظ على أداء التطبيقات وقابليتها للصيانة كتوسيع نطاق التطبيقات.
تساعد Ember Engines والوظائف الإضافية في الريبو في الحفاظ على الأجزاء الاختيارية من التطبيق معيارية وقابلة للتثبيت للمستخدمين النهائيين.

يتم استخدام Ember بشكل كبير من قبل أنظمة إدارة المحتوى الأخرى ويمكن البناء على هذا الجهد والتعلم منه ومشاركته.
كما ذكرنا في تعليق سابق على مدونة m ، يستخدم Ghost Ember للمشرف والمحرر ، ولكن Ember يُستخدم أيضًا مع شركات Drupal مقطوعة الرأس ، و Cardstack ، وشركات المحتوى مثل Conde Nast و Bustle والمزيد.
هذا يعني أن الميزات الشائعة مثل قوائم العلامات والمحررين المستندة إلى المكونات (على وجه التحديد محرر Mobiledoc ) والمزيد متوفرة كجزء من نظام Ember Addon البيئي .

من خلال تجربة المجتمع والمطور ، فإن Ember يطابق بشكل أفضل نظام Wordpress البيئي (كمطور عمل في Wordpress لأكثر من 5 سنوات).
لدى Ember العديد من أفضل الممارسات سواء كانت مدمجة أو موثقة جيدًا أو متاحة عبر الإضافات ؛ هذا يقلل من السؤال "هل سيعمل هذا مع تطبيقي" ويساعد على تقليل الأخطاء المحتملة في الأمان أو الأداء بشكل أفضل.
تم تصميم Ember على أساس تجريدات قابلة للتخصيص مما يعني أنه يمكن استخلاص التعقيد من المطورين النهائيين ويمكن أن تكون التعليمات البرمجية الصعبة محدودة النطاق لجعل التخصيص سهلاً وممتعًا.
تتطابق إضافات Ember بشكل وثيق مع المكونات الإضافية والسمات الخاصة بـ Wordpress حيث يتم اكتشافها تلقائيًا ولديها تكوين افتراضي خارج الصندوق ، ولكن يمكن تخصيصها بشكل أكبر لتلبية احتياجات المستخدم النهائي.
توجد أداة حالية لتنظيم Ember Addons تسمى Ember Observer للمساعدة في العثور على الإضافات الأكثر شهرة وأفضل صيانة وأكثر استقرارًا.

كاليبسو وجوتنبيرج مشروعان كبيران وطموحان لهما احتياجات ناضجة. لدى مجتمع Ember حلول ناضجة لإمكانية الوصول والتدويل ومتطلبات أخرى لتطبيقات الويب الحديثة.

أنا جزء من فريق التعلم Ember.js وأعمل عن كثب مع المساهمين الأساسيين ، أود التحدث أو إجراء محادثة مع أعضاء فريق Ember الآخرين حول كيفية تلبية Ember و Glimmer لاحتياجاتك.

لقد لاحظت أنه تم ذكر بوابات React وأود أن أضع في 2 another أخرى أن Ember لديها ملحق جيد الصيانة يسمى Ember Wormhole لتوفير هذه الوظيفة والعديد من الإضافات التي تبني فوق ذلك لتوفير ميزات مثل الحوارات وتغييرات رأس المستند ، و اكثر.

سأصوت لصالح Marko لأنه يدعم التقديم غير المتزامن الأصلي والأداء السريع من جانب الخادم. !!!

@ patrick-steele-idem & mlrawlings - شكرًا على

سوف أحفر في المزيد.

لقد عملت مع Ember.js في مؤسسة كبيرة جدًا حيث كانت التطبيقات تعمل داخل تطبيقات أخرى وفي شركة صغيرة جدًا مع تطبيقات صغيرة قائمة بذاتها. ساعدت الآراء والاتفاقيات القوية لـ Ember.js في الحفاظ على قاعدة بيانات منتجة وقابلة للصيانة مع نمو الفرق والتطبيقات. فهي لا تتيح فقط القدرة على مشاركة الكود (عبر المحركات أو الوظائف الإضافية) عبر المشاريع ، ولكنها تتيح أيضًا للمطور الذي تعلم الاتفاقيات أن يكون منتجًا ويساهم في أي تطبيق من تطبيقات Ember.

كانت أكبر فائدة لـ Ember هي استقرارها دون ركود. دون الحاجة إلى تغيير أي من قوالبنا ، حصلنا على مزايا أداء هائلة عندما تم إصدار الإصدار الجديد من Ember الذي أعاد تشكيل محرك العرض لدينا بالكامل. تبدو مستويات التجريد مناسبة تمامًا لتطبيقات الويب الغنية الحديثة التي قد تنمو وتحتاج إلى توسيع نطاقها في المستقبل البعيد.

عندما تكون التغييرات ضرورية ، يمثل الترحيل مصدر قلق أساسي وتساعد أدلة الإيقاف في كل خطوة على الطريق (باستخدام أحدث تحويلات JavaScript AST / CST لترقية التطبيقات تلقائيًا).

غيرها من تطبيقات الويب شعبية التي تستخدم الجمرة التي لم تذكر من قبلrtablada تشمل Twitch.tv ، لوحة القيادة Heroku ، ترافيس CI ، و الخطاب .

بفضل SaladFork على التحديث ، بدأت بتسمية معظم الشركات في مجال إدارة المحتوى.

تتضمن بعض الأمثلة على تطبيقات Ember مفتوحة المصدر واسعة النطاق ما يلي:

• ترافيس سي
• Hospital Run - نظام EMR (سجل طبي إلكتروني) مصمم للاستخدام في وضع عدم الاتصال خاصة في حالة الاتصال المنخفض في إفريقيا
• شبح

لست متأكدًا من مقدار ما يمكنه الخوض في التفاصيل ، لكنني أتواصل مع

سأصوت لماركو لأدائها ومرونتها وبنيتها الواضحة وسهلة الفهم!

+1 لماركو أيضًا. بعد أن قمت بعمل الواجهة الأمامية بشكل جيد قبل أن أبدأ في فقدان الشعر وأصبحت رمادية (مثل ، منذ وقت طويل) ، فقد كان إطار العمل / المكتبة الأمامية التي كنت أبحث عنها طوال هذه السنوات. إنه سبب كبير يجعلني أحب العمل في eBay مع @ patrick-steele-idem و mlrawlings أيضًا.

لقد صوتي Marko JS. تم الاستخفاف به للغاية نظرًا لسهولة الاستخدام والأداء.

أنا أحب marko-widget جنبًا إلى جنب مع Marko الفعال. ببساطة إطار عمل متميز ورائع. طريقها أسرع من الأطر الأخرى. المعيار هنا

لقد أصوت لصالح MarkoJS ، لقد كنا متجرًا للمقاود لسنوات عديدة.

عندما اتخذنا الخطوة الإستراتيجية للدخول في الخدمات الصغيرة وتمكين البنية القائمة على المكونات لمنصتنا ، كنا نبحث عن إطار العمل الصحيح لتحقيق التوازن بين كل من العرض من جانب الخادم وتقديم العميل. نحن عبارة عن منصة تحتوي على إعلانات مبوبة في 6 أسواق مختلفة بما في ذلك الأسواق الناشئة مثل جنوب إفريقيا والمكسيك ، حيث تمثل البيانات مصدر قلق كبير ونحتاج إلى موقع يكرم حقًا متطلبات تصفح المستخدم على الأجهزة التي يبلغ عمرها بضع سنوات وتستخدم أيضًا بيانات أقل. أيضًا ، سوف يتنقل المستخدم في الموقع ذهابًا وإيابًا حتى يجد عنصرًا يرغب في شرائه ، مما يعني أننا بحاجة إلى عرض خادم سريع حقًا يحدث أثناء تنقل المستخدم.

بعد دراسة متأنية ، اخترنا MarkoJS مع حقيقة أنه يدعم:

1. عرض خادم سريع مع أداء خادم جيد
2. يدفع البايت الأول في أسرع وقت ممكن
3. القدرة على بناء مكونات ثانوية وعرضها بشكل غير متزامن عندما تكون البيانات جاهزة
4. القدرة على بناء بنية مكونات التوصيل والتشغيل
5. قم بزيادة عرض العميل إلى الحد الأقصى باستخدام نفس البنية أو بنية أفضل من React / Vue.
6. الاختبارات المعتمدة على المكونات التي يمكن استخدامها ليس فقط لاختبار العرض ، ولكن لحالة المكون

(قصة نجاح من إعلانات eBay المبوبة)

+1 لـ Angular (NOT AngularJS).

إن Angular CLI هو الأفضل من بين جميع الأطر إلى حد بعيد ، ومع خطط الترحيل في المتجر من أجل الترحيل السلس بين الإصدارات ، سيكون مناسبًا جيدًا.

تم اعتماد Plus Angular بشكل جيد في عالم المؤسسة ، حيث يمكن أن يستخدم WordPress بعض الحب إذا استمر WordPress في النمو كمنصة للمستشارين والمستقلين ، ولن يكون مجرد سباق إلى الأسفل.

لديها مجتمع قوي من المطورين من جميع المستويات. دائمًا ما يكون الفريق الأساسي رائعًا للتحدث مع ما إذا كانوا يعملون لصالح Google أم لا. يعد WordPress إلى حد كبير (بالنسبة لمعظم المطورين رفيعي المستوى) مجتمعًا يشاركون فيه ، لذلك سأقول إن المجتمع Angular مناسب تمامًا

لقد تحدثت مؤخرًا عن Vue في بيئات تقديم الخادم مؤخرًا (يتم عرض الشرائح هنا ) ، وبعد أن عملت مع بيئة .NET خلال الأشهر القليلة الماضية ، أنا مقتنع بعدم وجود أي خيار آخر للعمل في البيئات مثل هذا. يمكنك الحصول على مزيج ممتاز حقًا من القدرة على تحديد مكونات ما يجب سحبه إلى JS للتفاعل الثقيل مع السماح للواجهة الخلفية بمواصلة التحكم في الموقع في الغالب.

مما يعني أنه مثالي إلى حد كبير للبناء فوق ما يتوفر عليه WordPress الآن. ستتطلب أي مكتبة JS أخرى يعرضها الخادم على الأرجح عقدة. Vue لا. يمكنك تسجيل مكون مثل <gutenberg-editor> وجعل WordPress يرسل <gutenberg-editor> في HTML. يمكن لـ Vue استخدام HTML الذي أرسله WordPress لبدء تشغيل الصفحة. إنه يشبه إلى حد ما مكونات الويب في هذا الصدد ، ولا يتطلب قطعة أخرى من تقنية BE للحصول على عرض الخادم.

إنه أحد الأسباب التي تجعل إطار عمل مثل Laravel يختاره كإعداد افتراضي: من السهل جدًا دمجه في نهايات خلفية غير Node. أعتقد أن WordPress يجب أن يعتمده لنفس الأسباب.

لقد قمت بالتصويت لصالح Vuejs .
نفس الحالة مع borantula على تعليقه

قدم كبير مسؤولي التكنولوجيا في بلدي Vuejs إلى الفريق - الوافدون الجدد إلى الواجهة الأمامية ، وسرعان ما دخلوا فيه ، والآن أصبحوا سعداء مع Vuejs. يستخدم فريقي WordPress في العديد من المشاريع.
حاليًا ، نحن نستخدم Vuejs و Custom Element لإنشاء الواجهة الأمامية لمشروع يستخدم WordPress في الواجهة الخلفية. يعمل بسلاسة كبيرة.

كما قال @ blake-newman و Evan ، لم تعد Vuejs تعتمد على شخص رئيسي واحد بعد الآن ، لذلك يمكن القول أن العيوب التي ذكرها

تعمل MARKO بشكل جيد في تطبيق الويب الخاص بنا. يعمل العرض التدريجي مثل السحر.

لا يمكنني قول أي شيء عن Preact أو MarkoJS (يشار إليه بشدة في التعليقات) ولكن يمكنني التحدث عن Vue حيث قدمته لفريقنا (يعمل بشكل أساسي على php + jQuery في ذلك الوقت) منذ عام مضى ويغير فهمهم لجافا سكريبت تدريجيًا ، الخروج من الحالة الذهنية لـ jQuery.

أعتقد أنه سيكون اختيارًا جيدًا ليس فقط لـ Gutenberg ولكن للهدف طويل المدى لـ WordPress ، الانتقال إلى نظام أساسي أكثر توجهاً لواجهة برمجة التطبيقات مع المزيد من جافا سكريبت على الواجهات. من الأسهل منحنى التعلم والألفة ستشجع مطوري WP الآخرين على التدخل أيضًا.

لقد رأيت كيف يزدهر VueJS في مجتمع Laravel وأصبح تقريبًا خيارًا فعليًا لمعظم الناس ، وأعتقد أنه سيكون كذلك في مجتمع WordPress.

Backbone.js

/س

كنت أرغب في تقديم دعمي وراء MarkoJS.

قبل عامين ، نقلت البنية التحتية لشركتي من ExpressJS و Jade (الآن PUG) إلى Marko JS. أرادت شركتي إنشاء مكونات معقدة وقابلة لإعادة الاستخدام عبر نظامنا البيئي بأكمله. أراد المطورون السرعة وقابلية إعادة الاستخدام. أراد المصممون تقليل حمل التصميم. لم ننظر إلى الوراء منذ ذلك الحين.

لدينا الآن مواقع ويب متعددة تواجه العملاء مكتوبة بلغة Marko ونظام CMS كامل أيضًا.

في النهاية ، اخترت MarkoJS لما يلي:

• عرض خادم سريع حتى مع أطر مثل Koa و أو ExpressJS
• يعالج العرض غير المتزامن لبيانات الصفحة
• القدرة على بناء مكونات التوصيل والتشغيل لنظام بيئي أكبر
• أداء أفضل من React / Vue
• تركيب قالب سهل للغاية

أود أيضًا أن أشير إلى أن فريق MarkoJS كان حقًا ممتازًا. لقد كان @ patrick-steele-idem و mlrawlings دائمًا على

👍 لـ MarkoJS

Preact هي مكتبة متوافقة مع React-API مما يعني أن Preact تستفيد مباشرة من النظام البيئي لـ React والعدد الكبير من حزم / مكونات OSS المتاحة. نظام Vue البيئي أصغر بكثير بالمقارنة. وثائق حزم / مكونات Vue للجهات الخارجية باللغة الصينية.

من فضلك ، لا مزيد من "أصوت XYZ" ، فهم لا يفعلون شيئًا لإضافته إلى المحادثة سوى إرسال ردود غير ضرورية إلى الأشخاص المشتركين في هذه المشكلة

🔥 الزاوي

• PRO: أكبر منافس للرد
  لكثير من الناس. غالبًا ما يكون السؤال هو "Angular or React؟" / "رد الفعل أم الزاوي؟". يمكن القول إن المجتمع Angular هو الأكبر بين بدائل React ، وينمو بسرعة.

• PRO: الكثير من مصادر التعلم
  بالإضافة إلى مستندات وأدلة API الرسمية ، ربما تمتلك Angular أكبر نظام بيئي للمواد التعليمية ومنشورات المدونات والكتب والعديد من دورات الفيديو ، سواء المجانية أو التجارية في كل منصة تعليمية رئيسية ، بالإضافة إلى Google GDEs التي تدرسها في ورش العمل والمؤتمرات.

• PRO: يتكامل جيدًا مع Redux
  إما بشكل مباشر أو عبر Ngrx المدعوم من RxJS (بدعم من عضو فريق Angular)

• PRO: الأفضل في دعم الأدوات

  • CLI لديها ميزات أكثر من غيرها

  • دعم محرر جيد جدًا في VS Code خاصة مع خدمة اللغة

  • مكتوب من أجل TypeScript ، يوفر أفضل تجربة في TypeScript

• PRO: ميزة غنية ، عنيدة ، ومنظمة بشكل افتراضي
  الفصل المنطقي عبر Angular Modules (NgModule) ، بالإضافة إلى الميزات القياسية للنماذج ، ومكالمات HTTP ، والتوجيه ، وما إلى ذلك يجعل من السهل على المطورين الآخرين قراءة التعليمات البرمجية والمساهمة فيها

• PRO: أفضل تكامل مع RxJS
  مفيد للعديد من تدفقات API والعديد من تدفقات الأحداث في صفحة واحدة بشكل عام

• PRO: نظام DI المدمج (حقن التبعية)
  مفيد لإنشاء نقاط قابلية للتمدد وربما حتى نظام مكون إضافي ، خاصة عند دمجه مع RxJS

• PRO: العديد من الصناديق الأخرى التي تغطيها المكتبات الأخرى

  • مكتبات واجهة المستخدم ذات التراخيص المسموح بها
    هناك PrimeNg و Angular Material 2 و ngx-bootstrap وغيرها الكثير ...

  • تحميل كسول
    دعم مدمج لطرق التحميل البطيء ، كما يدعم وحدات التحميل البطيئة يدويًا أيضًا

  • CSS الخاصة بالمكونات
    يضمن تحديد نطاق CSS للمكون فقط ، وتحميله فقط عند تحميل المكون ، ولديه خطافات لـ CSS العالمية

  • التقديم من جانب الخادم
    تعمل بالفعل مع Node و ASP .NET Core ، وتحصل على تركيز أفضل هذه الأيام

  • اختبارات
    يوفر Angular مساعدين للاختبار اللاأرشادي لاختبار الوحدة مما يجعل اختبار الوحدة أمرًا سهلاً للغاية. يولدون الاختبارات بشكل افتراضي من CLI باستخدام Jasmine ، والتي يمكن تحويلها بسهولة إلى Jest. كما أنها توفر غلاف سيلينيوم اختياري منقلة لتسهيل اختبار E2E (على الرغم من أنك لست بحاجة إليه حقًا ، فأنا أستخدم Selenium .NET لتطبيقات Angular الخاصة بي ، ولا شيء محدد من Angular ، لكنهم يحاولون جعله أسهل)

  • دعم الهاتف المحمول / PWA
    تعد Google أكبر داعم لـ PWAs ، ويتم عرض الدعم في Angular CLI بالفعل مع Service Workers and Universal (دعم من جانب الخادم) ، و Ionic (دعم كوردوفا) ، و NativeScript (التطبيقات الأصلية)

• PRO: التركيز على دعم المتصفح
  مع وجود صفحة polyfills مخصصة في المستندات ، وإدخال polyfill (مُعلق) افتراضيًا في CLI ، يبقيك Angular في حلقة من polyfills الدقيقة التي تحتاجها لنقل IE <= 11 ، لذلك لا تحتاج إلى تحميل polyfill أكبر بكثير مجموعة من دون سبب. هذا لأنهم يهتمون بدعم المتصفح.

• PRO: دعم شركة كبيرة
  Angular هي واحدة من المكتبات القليلة التي تمت مناقشتها هنا (الوحيدة؟) التي تدعمها شركة كبيرة.
  من خلال الدعم هنا ، ليس فقط شركة استخدمتها في عدد قليل من المشاريع وساهمت مرة أخرى في النظام البيئي ، ولكن كونها مشرفين رسميين يدفعون للمطورين والكتاب التقنيين للعمل بدوام كامل ، والاستثمار في قادة المجتمع (GDEs و DevRel في هذه الحالة جوجل).
  هذا هو PRO وليس CON لأنه يأتي مع ترخيص MIT مع عدم وجود بنود إضافية أو ملاحظات إبطال أو أي شيء آخر يمكن أن يكون مربكًا أو مخيفًا لبعض الأشخاص.

لقد قمت بتطبيق Vuejs لبعض المشاريع مثل المكونات الإضافية ، REST API. يجب أن أقول أنه من السهل التعلم ، ولديه الكثير من الميزات ، كما أن المجتمع الضخم ونظامه البيئي جيد أيضًا.

في الوقت الحاضر ، تنمو Vuejs بسرعة. سيكون اختيارًا حكيمًا إذا تم دمج Vuejs في كود WordPress.

cyberwanievoratecthephilip وغيرها.

رد ntwb بالفعل على التعليق التالي:

من فضلك ، لا مزيد من "أصوت XYZ" ، فهم لا يفعلون شيئًا لإضافته إلى المحادثة سوى إرسال ردود غير ضرورية إلى الأشخاص المشتركين في هذه المشكلة

لذا ، من فضلك توقف عن الإدلاء بتعليقات عديمة الفائدة. لإظهار دعمك ، يمكنك استخدام github emojis لإبداء الإعجاب بتعليق لصالح مكتبتك.

Vue.

بالمناسبة ، هناك Alibaba وراء Vue الآن ، وكذلك مشروع Weex Apache الذي يمكّن Vue api على الهاتف المحمول.

كنت سأضع بعض الاعتدال هنا ، الكثير من المعجبين بدون حجج واضحة

هذا هو التحذير الأخير ، والخطوة التالية هي أن نبدأ في حذف التعليقات ...

أنا ، نفسي ، لم أستخدم Marko أو Preact أو Vue.js ، لست على دراية بأي منهم لأكون صادقًا ، أود أن أسمع وأقرأ ما يقوله مجتمع WordPress حول هذه الأطر ، كل منها ، المزايا التقنية لكل منها ، والنظام البيئي المحيط لكل منها ، وأدوات البناء ، وأخيراً وليس آخراً الأشخاص والمجتمعات التي تقف وراء هذه المشاريع. 😄

لا أريد قراءة "تصويتي لـ XYZ" ، إذا كنت ترغب في إضافة تصويت ، فانتقل لأعلى وأضف رد فعل emoji _thumbs up_ إلى إطار العمل الذي اخترته والذي سبق ذكره أعلاه. 👍

لم يستغرق الأمر وقتًا طويلاً حتى يظهر تعليقان جديدان منذ تعليقي السابق 😞

تحقيقا لهذه الغاية ... إذا تمت إضافة تعليقك بعد https://github.com/WordPress/gutenberg/issues/2733#issuecomment -329705942 وكل ما قلته هو _ "أصوت لـ XYZ" _ أو نص لذلك تأثير يحظى بفرصة حذف عالية جدًا لتعليقاتك ، كما ستتم إزالة التعليقات المستقبلية من نفس النوع.

إذا كنت تعود إلى هذه المشكلة وتتساءل عن سبب حذف تعليقك ، فهذا هو السبب

ahmadawais لدي بعض التعليقات.

هجرة جوتنبرج من React إلى ...؟

بخصوص:

patrickgalbraith هذا في الواقع هو السبب الخاطئ للنظر في Preact. يجب الحكم عليها بناءً على مزاياها وليس لأنه من الأسهل الانتقال إليها. يمكنني رؤية المشكلات التالية مع Preact

• مجتمع أصغر مقارنة بـ VueJS
• روائح الكود - قد يؤدي الانتقال إلى مكتبة مشابهة جدًا إلى إجبار الممارسات السيئة (للسبب الواضح لكونها المسار الأسرع)
• يشبه التمسك بـ Preact الالتصاق بـ React على أي حال (اقرأها في مؤشر ترابط)

أعتقد أنه عندما يكون لديك مشروع بعدد غير بسيط من أسطر التعليمات البرمجية ، يجب أن تكون حذرًا للغاية. يحب المهندسون إعادة كتابة الأشياء ، وتعلم لغات وأطر عمل جديدة ، ويعتقدون أنهم سوف يقومون بعمل أفضل إذا تمكنوا من إعادة كتابة هذا الرمز ... تحدث جويل عن خطر إعادة الكتابة ببلاغة منذ وقت طويل .
سيوفر لك استخدام Preact الكثير من الوقت. يمكنك التقليل من الوقت الذي ستستغرقه للانتقال إلى إطار عمل جديد تمامًا. لست متأكدًا من سبب كتابتك "هذا في الواقع سبب خاطئ للتفكير في Preact". بصفتي مهندسًا ، تحتل التكاليف والوقت اللازم للتسويق مكانة عالية في قائمة المعايير التي أستخدمها لتقييم واختيار الحلول.
إذا كانت المشكلة حقًا هي براءة اختراع Facebook ، فإن Preact يحلها بتقليل التكاليف. يعد Preact أكثر كفاءة من React وحتى Vue: مساحة أصغر وعرض وقت تشغيل أسرع. تحقق أيضًا من كتابة Addy Osmani عليها .

لست متأكدًا من كيفية تقييمك لحجم مجتمع Preact. إذا كنا نتحدث عن النظام البيئي والمكونات المتاحة ، فإن استخدام Preact يمكّنك من استخدام معظم مكونات React مفتوحة المصدر. لذلك من الناحية العملية ، لديك أشخاص حتى لو لم يكونوا يعملون بشكل صريح على Preact ، فهم لا يزالون ينتجون كودًا يمكنك الاستفادة منه. لا يزال بإمكانك اعتبار النظام البيئي لـ React جزءًا من النظام البيئي لـ Preact.

لماذا لا يزال Vue هو خيارك المفضل؟

أشعر أن النقطة الثالثة هنا "التمسك بـ Preact مثل التمسك بـ React على أي حال" هي على الأرجح السبب الرئيسي الذي يجعلك مترددًا في اختيار Preact. هل انا مخطئ ما هو الخطأ في React بجانب براءة اختراعها؟

النظر إلى الصورة الكبيرة

قرأت أن كل ما تختاره لـ Gutenberg سيتم استخدامه أيضًا في Calypso.
يستخدم جوتنبرج React فقط في الواجهة الأمامية. عندما تنظر إلى عرض جانب الخادم ، يصبح الموقف أكثر تعقيدًا ولكن لا يزال خيار الترحيل المسبق يبدو أسهل.

أعتقد أنك بحاجة للنظر في المعايير الخاصة بك. إذا كنت تفكر بجدية في إعادة الكتابة ومن المهم الاحتفاظ بالعرض المتماثل ، فإن

إذا بدأت من الصفر وكنت على استعداد لتجاهل النظام البيئي لـ React ، فإن MarkoJS لا يحتاج إلى تفكير.

أنا أنظر إلى العروض ويبدو أن MarkoJS ليس لديه أي منافسين . 40x أسرع من React ، و 10x أسرع من Vue و 6x أسرع من Preact هو مجنون. في كتابي ، 30٪ من التحسينات غير ذات صلة ولكن عندما يكون لديك أكثر من 10 أضعاف التحسن ، فأنت بحاجة إلى الانتباه بجدية.
عندما يكون لديك حضور ناجح متواضع ويمكنك استخدام 10 خوادم بدلاً من 100 ، أو 2 بدلاً من 20 ، فإن ذلك يحدث فرقًا كبيرًا.

الإفصاح الكامل ليس لدي أي ارتباط عاطفي بأي من Preact أو MarkoJS. أعتقد فقط أنها أكثر منطقية من البدائل من منظور هندسي.

حظ موفق بقرارك 😃

MustafaHosny اللهم امين ...

أنا من عالم دروبال (نشاهد هذه المسألة: D) لذلك ليس لدي أي رهانات في هذا. لكن عند قراءة التعليقات ، من الواضح أن هناك حوالي 5 أطر "عليا" هنا والجميع يحب الإطار الذي اختاروه لذلك سيعطونه الدعائم.

جانب السرعة غير ذي صلة هذه الأيام حقًا. العاملان الوحيدان اللذان يجب أخذهما في الاعتبار هما أ) هل تريد حقًا إعادة كتابة كل شيء و (ب) كيف سيكون انتقال مطوري React وكيف سيكون تعلم المهاجم الفائز بالنسبة للمطورين الجدد.

هناك طبقات متوافقة ، جهنم ... للانتقال السهل ولكن الأداء سوف يتأثر. من ناحية أخرى ، ستجعل الانتقال أمرًا رائعًا بمرور الوقت ، ولا يلزم إعادة كتابة كل شيء مرة واحدة. من وجهة نظر الأعمال ، هذا أمر لا يحتاج إلى تفكير. من المجتمع POV والمستقبل لا فرق.

الآن DX هو المكان الذي يكمن فيه كل شيء. يجب ألا يواجه أي شخص متمرس في مهاجم تفاعلي أي مشكلة في الانتقال إلى مهاجم جديد لمجرد أن المفاهيم هي نفسها ، ولكن يختلف فقط بناء الجملة. لكن المبتدئ ، هذا هو المهم. ما مدى صعوبة / سهولة أن تكون منتجًا في مهاجم جديد. ما مدى صعوبة / سهولة قراءة وفهم الكود الموجود. وهذا يعتمد فقط على أ) التوثيق الجيد و ب) المجتمع (المنتديات ، SO ، غرف الدردشة ، المدونات ..).

لن أقول أي مهاجم أفضل منذ أن قلت ، أنا لست رجل WP. لكنني أردت أن أعطي 2c لإبقاء رأسك هادئًا عندما يتعلق الأمر بمثل هذا القرار الكبير الذي سيؤثر على الآلاف من المطورين حول العالم.

ntwb : لم يتم حذف تعليقي ولكني أعتقد أن حذف التعليقات ، حتى تلك الخاصة بالفتيان المعجبين ، كنوع من الرقابة.

لماذا ا:

إذا تمت إضافة تعليقك بعد # 2733 (تعليق) وكل ما قلته هو "أنا أصوت لصالح XYZ" أو أن هناك فرصة كبيرة لحذف تعليقاتك بهذا المعنى ، فستتم أيضًا إزالة

أرى الكثير من تعليقات المعجبين فوق ذلك. لماذا يبقون؟
يبدو أنه معيار مزدوج.

الزاوي ، إنه اختيار واضح. أعتقد أن روي وميليجي يحققان نقاطًا رائعة ويدعمانهما بنسبة 100٪. ينتقل WordPress إلى عالم Enterprise ليس فقط في الاستخدام ، ولكن أيضًا من حيث منهجية تطويره.

سأقوم بربط مصدر ممتع: https://vuejs.org/v2/guide/comparison.html وعلى وجه الخصوص: "... يرجع تعقيد Angular إلى حد كبير إلى هدف تصميمه المتمثل في استهداف كبير ومعقد فقط تطبيقات ... ". هذا البيان البسيط يضرب الظفر في الرأس. WordPress هو ، وسيظل اتجاهه المستقبلي ، تطبيقًا قويًا معقدًا.

ChrisCinelli ببساطة لأن ذلك عندما طلبنا من الأشخاص الامتناع عن قول "أنا أصوت لصالح xyz" ، فأنا أفهم من أين أتيت على الرغم من أنني أعتقد أن إزالة هذه التعليقات سيكون شكلًا سيئًا ، فأنا لست مولعًا بحقيقة أنني اضطررت لذلك قم بإزالة أي منهم

لم أحضر هذا سابقًا لأنني لم أرغب في مهاجمة الأطر التي لم أوصي بها (بعد أن أوصت Angular أعلاه) ، ولكن فقط من أجل الاكتمال ، هناك شيء يجب محوه باستخدام Preact ومكتبات أخرى شبيهة بـ React . سأضعه هنا ، والأمر متروك لـ WordPress لتقرير ما إذا كان يمثل مصدر قلق.

فيما يلي اقتباس من منشور كتبه محامي براءات الاختراع / الملكية الفكرية بترخيص React ، (يتم نسخ تمييز غامق من المصدر):

لقد حصلت على الكثير من "حسنًا ، فلنستخدم جميعًا [إطار عمل بديل هنا]." انتظر لحظه. إذا كانت براءات اختراع Facebook تغطي React (اختلاف ، تكوين ، إلخ) ، فمن المحتمل أن تغطي براءات الاختراع هذه Preact / Vue / et al.

لكن React تمنحك براءة اختراع! مع إطار عمل بديل ، أنت منتهك منذ اليوم الأول. يعود كل هذا إلى ما إذا كان لدى Facebook براءات اختراع ورغبتهم في إنفاذها ، ولكن إذا كنت ترغب في ممارسة لعبة الحرب إلى الدرجة التاسعة ، فإن بدائل React تكون أكثر خطورة .

الآن ، إذا كان فهمي صحيحًا ، فإن WordPress لا يغادر React لأنه قلق بشأن الترخيص نفسه ، ولكن فقط بشأن الاضطرار إلى حمل هذا الترخيص لمستخدميه ، وبالتالي جلب الارتباك والحاجة إلى الدفاع عن القرار لنفسه.

بالانتقال إلى بديل React ، قد يكون هناك القليل للدفاع عنه إذا كان الترخيص البديل مسموحًا به ، ولكن قد يكون هناك أيضًا بعض الالتباس في WordPress.

الأمر متروك لـ WordPress لتقرير ما إذا كان هذا أمرًا يدعو للقلق أم لا.

شكرا لك ChrisCinelli على نقدك البناء. أرحب به بأيد مفتوحة.

بصفتي مهندسًا ، أعرف أن التكلفة والوقت على رأس القائمة. لكن هذا هو الشيء. هذا ليس مشروع شركة معينة. الأهداف هنا مختلفة.

الهدف هو العثور على JS FW وهو أمر جيد للمجتمع. لم يتم إطلاق Gutenberg بعد. إذا نجح الأمر ، فسيكون Preact هو الفائز الواضح.

الآن نحن بحاجة إلى الاهتمام بهذا:

• من السهل اعتماد JS FW لمجموعة أكبر من المجتمع
• يجب أن يكون لدى JS FW الذي نختاره مجتمعه ونظامه البيئي الخاصين به
• يعد وجود سجل حافل مع برنامج FOSS للإنتاج يعتمد على PHP ميزة إضافية. Vue + Laravel
• اختيار JS FW بناءً على مزاياها وليس فقط لأنه من السهل الانتقال إليها

في 11 عامًا قضيتها مع WordPress ، وبصفتي مساهمًا أساسيًا منتظمًا ، أعتقد أن اختيار Preact سيخلق الكثير من الفوضى. منحنى التعلم ضخم بالفعل للمطورين المتوسطين / الجدد.

يمكن أن يؤدي وضعهم في فوضى توافق Preact-React في بداية هذه المرحلة الجديدة من تحسين WordPress إلى مغادرة مجتمع WordPress وتعلم شيء آخر باستخدام منحنى التعلم المماثل. (_HINT_: Laravel + Vue بدلاً من WordPress + Preact + React) وبالمناسبة ، هل نسيت أن هذا ما يحدث مع دروبال 8؟

الرجاء عدم إزالة التعليقات المدنية. من الواضح أن هناك حاجة أو رغبة ماسة في إبداء رأي حول هذه المسألة. أرى أنه أمر جيد لأن الناس يقولون إنهم يهتمون بـ WordPress ويريدون أن يتم سماعهم. تذكر أنه تم توجيه مجتمع WordPress ، وليس فقط مطوريه ، إلى Github لتقديم ملاحظات. إذا كنا حقًا لا نستطيع تحمل تعليقات 1+ ، فقم بإضافة عدد في الأعلى يحتفظ بأسماء المستخدمين.

إذا كنت تبحث فقط عن مناقشة منطقية ، فإن الكثير من تعليقات "أنا أصوت لصالح X أو Y أو Z" قد تبدو مجرد ضجيج ، ولكن هناك نمط واضح ناشئ من الأشخاص الذين يدعمون Vue.js. رأيي في ذلك هو أن لدينا مئات ، أو بضع مئات ، من الأشخاص الذين سيساهمون بالكود في Gutenberg ، لكن عشرات الآلاف سيكتبون المكونات الإضافية والسمات التي تتفاعل معها. لن يكون نجاح Gutenberg مجرد تجربة للمستخدم النهائي ، ولكن أيضًا تجربة التطوير. إنه ليس الشيء الوحيد ، ولكن الشيء المهم الذي يجعل WordPress ناجحًا هو أنه قابل للتوسعة بسهولة.

على الرغم من أنه ليس لدي إطار عمل محدد في الاعتبار ، إلا أنني أود أن أقول إن شيئًا واحدًا يجب أن نضعه في الاعتبار هو أن دعم المستعرض بدأ في الظهور في مكانه مع مكونات الويب ، أو إطار العمل الذي يستخدم مكونات الويب أو على الأقل مكوناته المبنية مثل سيكون لهم دليل في المستقبل. هناك أيضًا polyfills لجلب مكونات الويب إلى المتصفحات التي لا تدعمها.

لقد ذكرت سابقًا وقد جئت للتو إلى هنا لإيقاف تشغيل الإشعارات ، لكنني سأفكر قليلاً.

إذا كنت تقوم بإنشاء تطبيق صفحة واحدة من البداية ، فالوقت جوهري ، وتريد إطار عمل مدعوم جيدًا وموثق وقابل للاختبار ، فلدي الكثير من التجارب الملموسة التي تُظهر أنه أقل تكلفة بكثير من حيث الوقت والكنز اذهب مع إمبر.

إذا كنت تقوم ببناء المزيد من PWA أو تقوم بإسقاط المكونات في صفحة يعرضها الخادم ، فإن Ember يعد خيارًا سيئًا ، ويمكنني أن أرى سبب جاذبية شيء مثل Vue.

سأضيف ذلك من جانب الأشياء المدفوعة بالاتفاقية ، لقد قمت بإنشاء عدد قليل من PWAs مع> 90 من نقاط المنارة باستخدام Ember.

في مشروعنا الأخير حيث احتجنا إلى القيام بذلك ، استغرقت العملية أقل من ساعة واحدة للحصول على درجة المنارة هذه ونشر التطبيق مع تمكين العرض من جانب الخادم.

يمكن أن تكون ذاكرة التخزين المؤقت SSR وعامل الخدمة اللازمة للحصول على درجات عالية من المنارة عملية صعبة للغاية.
مع Ember ، هذه العملية سهلة للغاية ولا تتطلب سوى تثبيت عدد قليل من الإضافات الموثقة جيدًا والمحافظة عليها (لمعظم التطبيقات).
من واقع خبرتي ، يأتي Preact مع هاتين الميزتين خارج الصندوق في Preact CLI ، ولكن هناك اتفاقيات (P) React الشائعة التي يمكنها كسر نتائج SSR.
مع Vue ، توصي المستندات الرسمية باستخدام Nuxt.js أو اتباع دليل SSR الكامل ؛ يقدم كلاهما المزيد من الأنماط التي يجب اتباعها خارج وثائق Vue الأساسية.

عدم إخبار أي شخص ، ولكن دعنا نتوقف عن حذف التعليقات على المشكلات ما لم تكن عبارة عن ألفاظ نابية أو مسيئة أحصل تمامًا على الأشخاص الراغبين في المساعدة وتركيز المحادثة ، لكن لا ينبغي أن ندخل في دوامة حذف التعليقات.

لست متأكدًا مما هو "موثق جيدًا" عن Ember مقارنة بـ VueJSrtablada .

أنا شخصياً سأواجه مشكلة في البدء في Ember مقارنةً بـ Vue أو حتى React.

ahmadawais ينسى الجميع أن هذا القرار سيكون له تأثير كبير وسوف ترغب في تغيير إطار العمل على أي حال في غضون سنوات قليلة. لذلك أنت ترغب في استخدام إطار الخير الحديث ولكن لا ترتبط به من أجل الحياة والموت. هل يبدو ذلك مستحيلا؟ ليست كذلك!

منذ بعض الوقت كانت لدي مشكلة مماثلة وبعد البحث والمحاولات توصلت إلى حل يحاول ربط الماء بالنار. بكلمات قليلة - عناصر مخصصة لمكون الويب ، تقنية التغليف التي تفضلها (مثل Vue ، React ، Angular) وكشف واجهة برمجة تطبيقات DOM القياسية.

في مثل هذا الحل سيكون لديك مكونات متعددة ولكل منها:

• الإطار الذي تريده (ولكن بالطبع يفضل أن يكون إطارًا واحدًا فقط)
• واجهة برمجة تطبيقات DOM القياسية التي يمكن للمكونات الأخرى استهلاكها بسهولة. يمكنك حتى التلاعب بها عبر JavaScipt العادي

أثناء عملي مع Vue في ذلك الوقت ، كتبت مهايئ Custom Element لـ Vue - https://github.com/karol-f/vue-custom-element - بحيث يكون لديك توافق فائق (على سبيل المثال ، إرسال Vue's $ emit حدث DOM قياسي يمكنه يمكن التقاطها عبر JS عادي أو على سبيل المثال React / Angular) وتوافق IE9 +.

أوصي بالنظر إلى مثل هذا الحل مثل:

• سيكون دليلًا على المستقبل
• لن يتم ربطه بأي إطار عمل تختاره اليوم
• سيرى المستخدمون عناصر HTML القياسية ويمكنهم التفاعل معها باستخدام إطار العمل الذي يحلو لهم أو حتى باستخدام JS العادي
• لن يكون هناك تهيئة Vue يدوية حيث سيخبرك المتصفح ومكون التكوين التلقائي إذا كان في الصفحة (يمكنك حتى تحميل مكون بطيء بهذه الطريقة)

و أكثر من ذلك بكثير.

مثل هذا الحل غير مرتبط بـ Vue - يمكنك استخدام أي إطار عمل آخر تريده. كما أن العناصر المخصصة لـ Web Component هي ميزة متصفح قياسية ولن تذهب إلى أي مكان!

مع تحياتي!

رأيي في ذلك هو أن لدينا مئات ، أو بضع مئات ، من الأشخاص الذين سيساهمون بالكود في Gutenberg ، لكن عشرات الآلاف سيكتبون المكونات الإضافية والسمات التي تتفاعل معها. لن يكون نجاح Gutenberg مجرد تجربة للمستخدم النهائي ، ولكن أيضًا تجربة التطوير. إنه ليس الشيء الوحيد ، ولكن الشيء المهم الذي يجعل WordPress ناجحًا هو أنه قابل للتوسعة بسهولة.

نقلا عن التعليق أعلاه بواسطة dmccan لأنه نقطة مهمة لدعم Vue.

لقد أضفى WordPress الطابع الديمقراطي على أكثر من مجرد النشر. أتساءل عن عدد المهن والأعمال التقنية الناجحة التي تم إطلاقها بسبب سهولة الوصول إلى WordPress. خاصتي بالتأكيد.

سأقوم برمي قبعتي لصالح VueJS. يشترك في قيادة لقاء JavaScript المحلي هنا أحد أعضاء الفريق الأساسي لـ VueJS ويبدو أنه الاجتماع الذي يمكن للأشخاص الذين حضروا الانضمام إليه أسرع بكثير من الآخرين. كانت تجربتي السابقة مع AngularJS ووجدت أن VueJS أسهل في التعلم وبدأت للتو في البرمجة على الرغم من أنني بدأت من الصفر.

أرى أن بعض الأشخاص يتحدثون عن مؤسسة وبالتالي Angular ، ولكن بينما قد يحتاج WordPress إلى بعض الحب في هذا المجال ، أعتقد أن القرار يجب أن يعتمد على الوظائف والوظائف بالإضافة إلى سهولة التعامل مع المطورين. من خلال المناقشات التي رأيناها حول المربعات الوصفية وما إلى ذلك ، يتم جلب مؤلفي المكونات الإضافية إلى عملهم "Gutenberg-ify" بدلاً من مجرد التخلي عن إذا / عندما يختفي المحرر الكلاسيكي.

بعض النقاط الإضافية التي يجب ذكرها حول

• PRO لا يتطلب بالضرورة استخدام مترجم أو يجبر كيفية استخدامه ويمكن تشغيله مباشرة على الويب كما يمكن لـ jquery

سيساعد هذا بشكل مذهل مطوري المكونات الإضافية على الاندماج مع Wordpress UI. يمكنهم إرفاق نسخة vue جديدة بأي جزء من الصفحة كأداة. يمكن أيضًا أن يتبنى مشروع Wordpress الكبير بشكل

• دعم PRO JSX و css-in-js أيضًا!

قد يساعد في ترحيل مشاريع WordPress الحالية باستخدام كود React / JSX بشكل أسرع إلى vue.js بمتطلبات تغيير أقل. (يوجد أيضًا ملحق babel: babel-plugin-transform-response-to-vue )

• FACT Vue تمامًا مثل Preact وعلى عكس Angular / React ليس مشروعًا مفتوح المصدر مملوكًا لشركة كبيرة مثل Google أو Facebook.

سيكون هذا شيئًا بالغ الأهمية لمشروع ضخم مثل Wordpress للهروب من حبس البائع المحتمل. إذا كان مشروعًا مفتوح المصدر غير مملوك لشركة ما ، فيجب على شخص ما أن يبدأ به (لذا فإن "تبعية الشخص الرئيسي" لا معنى لها على أنها CON ).

أصوت لصالح VueJS.
ليس لأنني أعرف شيئًا عنها ، ولكن لأنني لا أملك أدنى فكرة عن كيفية نطقها في اللغة الإنجليزية. ومع ذلك ، فقد استخدمت Joomla لسنوات وأعلنت أنها خاطئة طوال الوقت.

نكتة جانبا.
لا يناقش الكثير هنا إطار العمل الأفضل في دعم مربعات التعريف القديمة والحقول المخصصة. كانت React سيئة للغاية في ذلك ، كما نعرف الآن.

الآن ، فقط لإلغاء الاشتراك من هذه المشكلة.

من أجل تركيز المناقشة ، قمت بإنشاء مشكلة مهمة هنا: https://github.com/WordPress/gutenberg/issues/2741

أقترح Vue ، فقط لأن Laravel. تحول الكثير من مستخدمي WordPress غير الراضين عن المسار الذي استغرقه أو لا يزال يأخذونه ، إلى استخدام Laravel كإطار عمل CMS رئيسي ، مع الحفاظ على WP كخيار ثانٍ. تعد Preact مجرد طبقة توافق مستنسخة وضخمة ، نوعًا ما كان Novell DOS مع MS DOS و PC DOS والعكس.

cu، w0lf.

Vue.js على طول الطريق!

يجب عليك بالتأكيد إلقاء نظرة على Hyperapp .
الايجابيات

1. إنه مشابه جدًا لهندسة Elm (نموذج ، عرض ، تحديث).
2. يحتوي على Redux مدمج مثل Reducers يسمى "الإجراءات" (يسمى لتحديث النموذج وعرض بدوره).
3. يستخدم JSX
4. يشجع تصميمات "البرمجة الوظيفية"
5. يبلغ حجمها 1 كيلو بايت ، لذا من السهل تحميلها وفهمها.

سلبيات

1. إنه لا يزال جديدًا وكذلك النظام البيئي. لكن يمكنك التأثير فيه والمساهمة فيه.
2. قد تكون هناك مشكلات لم يتم الكشف عنها بعد.

تتوافق مبادئ كتل جوتنبرج بشكل جيد مع مبادئ مكونات الويب . إنه مستوى منخفض ، وحيادي في إطار العمل ومعيار ناشئ (مع polyfills ناضجة ومختبرة) - وهو مناسب تمامًا لـ WordPress

انظر أيضًا: البوليمر - مكونات الويب مع بعض السكر.

Vue هو خيار رائع ، وإليكم الأسباب التي أعتقد ذلك:

بدأت بمشاهدة Vue في أوائل عام 2016. لقد أحببته وأردت تحديد ما إذا كان سيكون "مطلوبًا" أو ما إذا كان نموه هو أي شيء أكتب عنه. في ذلك الوقت كان لديها 16000 نجمة على جيثب. لقد كان رائعًا وكل شيء ، لكن الناس لم يتكيفوا معه حقًا في خضم كل حماقات Angular vs React.

انتهيت من فقدان _جميع_ بياناتي وبدأت من جديد في 17 سبتمبر 2016. منذ عام واحد بالضبط ، اليوم. ( ها هي مجموعة البيانات الحالية الخاصة بي. )

على مدار العام الماضي ، شاهدت زيادة شعبية Vue (من حيث الإشارات على الإنترنت وتتبع نجوم Github) بمعدل كسر السجلات. جمعت Vue 40000 نجمة في 365 يومًا. هذا هو متوسط ​​109 في اليوم. وبالمقارنة ، نما محبوب العالم _React_ من 49000 إلى 75000 في نفس الإطار الزمني. (71 في اليوم) سيتجاوز Vue React في الأشهر القليلة المقبلة ، من حيث تقييمات المستخدمين.

بينما كان الجميع يتحدثون عن نمو React باعتباره الأكثر روعة في كل العصور ، لم يكونوا على دراية بأن Vue كان المالك الفعلي. لم يكونوا على دراية بأن Vue كان ينمو لأن الناس يحبونه بصدق كأداة ، وليس بسبب أي دعم مشهور (Facebook).

كان Vue في قائمة مستودعات جيثب الرائجة كل يوم لأكثر من عام الآن. 99٪ من الأيام يكون أعلى من React. 10٪ من الأيام ، رد فعل لا يقطع.

كل هذه الصيحات "استخدم Vue لأنها زادت شعبيتها!" ولكن ما أقصده هو أن Vue نمت لأن الناس يحبونها حقًا لأنها أداة رائعة وبديهية وقوية (غالبًا ما يتم تقديمها بشكل غير صحيح على أنها "رائعة للتطبيقات الصغيرة") للتطبيقات من جميع الأحجام. لكن ليس فقط أداة. Vue هو نظام بيئي. إنه يأتي مع مجتمع داعم ضخم أيضًا.

ربما أضيف ... ملفات .vue عبقرية. يتم إنشاء العديد من الأدوات للتعامل مع التصميم في React لأنه يبدو أن هناك خطأ ما في CSS Modules ووجود أنماطك في ملف خارجي. (Idk ...) لكن Vue ليس لديه هذه المشكلة. يحتوي Vue على عبارات تحكم مخبأة في بناء الجملة ، و (منذ أن رأيت تعليقات العناصر المخصصة أعلاه) لا يلعب فقط بشكل جيد مع العناصر المخصصة ... إنه _ مكتبة / إطار عمل للعناصر المخصصة المنطقية.

Preact رائع. بصراحة ، لقد بدأت للتو مشروعًا آخر معها اليوم. ولكن عندما ألقي نظرة على Preact أرى تفاعلًا خارج العلامة التجارية. لم يتم إنشاؤه ليكون مبتكرًا أو للتقدم بالطريقة التي نصنع بها البرامج المستندة إلى الويب. تم إنشاؤه ليبدو ويتصرف تمامًا مثل أداة موجودة مسبقًا ، ولكن لتقديم أداء أفضل.

هذا هو سنتي. الآن أنا مفلس.

آمل أن يجعلك قرارك النهائي سعيدًا ويوفر أساسًا رائعًا لمستقبل منتجاتك.

ahmadawais :

• يعد الوقت اللازم للتسويق أمرًا مهمًا لكل من المشاريع المؤسسية ومفتوحة المصدر. يمكنك العثور على أمثلة لمشروعات لم يتم شحنها مطلقًا لأنها استغرقت وقتًا طويلاً وعفا عليها الزمن قبل شحنها. انتهى الأمر بالتخلي عن عدد قليل من المشاريع أثناء العمل نحو إصدار رئيسي.
• معارضة Preact تعني "لقد ارتكبنا خطأ مع React لأسباب خارجة عن الترخيص". أعتقد أن "منحنى التعلم ضخم بالفعل للمطورين المتوسطين / الجدد" يعني أن مطوري WordPress قد فقدوا بالفعل مع React. لا يفاجئني. ولكن يبدو من الصعب تصديق أن Vue ، حتى لو كانت أقل إسهابًا ، ستحل مشاكل منحنى التعلم. يختلف محرك PHP WP القديم وأي إطار عمل جافا سكريبت لتطبيق صفحة واحدة اختلافًا كبيرًا. Vue و React متشابهان كثيرًا مع بعضهما البعض.
  لست متأكدًا من سبب رؤيتك للمنافسة بين Wordpress و Laravel. قد أكون ساذجًا هنا. أعرف القليل جدًا عن قصة دروبال 8.
  من وجهة نظري ، يعد Wordpress نظام إدارة محتوى وهو يجذب المطورين نظرًا لقاعدة مستخدميه الكبيرة من المستخدمين غير التقنيين والميزات المضمنة فيه بالفعل. هناك الكثير من القوالب ويمكن للمطورين إنشاء موقع جديد سريعًا يمكن تخصيصه بواسطة غير مطور.
  Laravel هو إطار عمل PHP ، على حد علمي ، لا يمنحك الكثير من ميزات CMS. سيختاره المطور لأنه يحتاج إلى مزيد من الحرية.
• لست متأكدًا من أن تحقيق بعض النجاحات مع Vue + Laravel يعني أيضًا "Vue مفيد لـ Wordpress". أعتقد أن هناك القليل جدًا من التآزر الجوهري بين PHP وأي إطار عمل JS. أوافق تمامًا على أنه من المهم إيجاد إطار عمل مفيد للمجتمع. إذا كان معظم مجتمع المطورين الحاليين الذي يعتمد عليه WordPress مألوفًا لـ Vue وكانوا يحبونه ، فهذا له وزن كبير في قرارك النهائي.

من منظور هندسي ، أعتقد أن كلا من Marko JS و Vue هما إطاران أحدثان. لقد تعلموا الكثير من React وتمكنوا من إزالة بعض الإسهاب فيها. بهذا المعنى ، يبدو أن ماركو يزيل المزيد من التعليمات البرمجية المعيارية أكثر من Vue. على وجه الخصوص ، يحتفظ Marko بتعليمة برمجية متماسكة من الجيد الاحتفاظ بها في نفس المكان وترك HTML ما هو جيد بالنسبة لـ HTML وفي Javascript مفيد لـ Javascript. وهو أيضًا أسرع 10x. إلى جانب حقيقة أن Vue لديه الكثير من المعجبين مؤخرًا ، لا أرى العديد من الأسباب لتفضيل Vue على Marko.

آسف ، لكن بناء جملة Marko وإعداده مروع بالمقارنة مع VueJS. من ناحية الأداء ، لم أر أي مصدر يكون MarkoJS فيه أسرع بأي طريقة مهمة دون إضافة الوقت لفهم كيفية عمله.

بناء الجملة @ bovas85 هو أمر شخصي ولكن لا أعتقد أن هناك أي أساس في ادعائك بأن تركيب ماركو "فظيع بالمقارنة". حقًا ، كانت الإصدارات المبكرة من Marko تحتوي على بناء جملة كان أقرب إلى بناء جملة Vue المستند إلى HTML ، وقد استقبل مستخدمونا الإصدار الذي قدم بناء جملة Marko الحالي جيدًا للغاية.

لقد وضعنا الكثير من التفكير في صياغة Marko للتأكد من أنها مألوفة للمطورين الذين يفهمون HTML و JS وأردنا أن تكون بسيطة وقوية قدر الإمكان مع الحد الأدنى من النماذج المعيارية. أعتقد أنك ستجد أنه مع أي مقارنة جنبًا إلى جنب ، سيتطلب نموذج Marko رمزًا أقل (وهو أمر رائع لسهولة القراءة وقابلية الصيانة).

إليك مستندًا قمت بتجميعه بسرعة حتى تتمكن من رؤية نظرة عامة على الاختلافات بين بناء جملة Marko وبناء جملة Vue:

بناء الجملة: Marko vs Vue

لقد ربطته سابقًا ، ولكن لمزيد من المقارنة المتعمقة بين Marko و Vue (و React) ، يرجى الاطلاع على:

Meetup: بناء واجهة المستخدم - مقارنة بين React و Vue و Marko (من صانع Marko) - فيديو | الشرائح

بالنسبة للأداء ، لدينا بعض المعايير التي يمكنك التحقق منها: https://github.com/marko-js/isomorphic-ui-benchmarks

فيما يلي عرض سريع للمعايير مع تمكين Marko و Vue:

أداء التقديم من جانب الخادم

_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

أداء من جانب العميل

_Chrome الإصدار 63.0.3218.0 (الإصدار الرسمي) كناري (64 بت) _

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

هذه هي المعايير التي أنشأناها لـ Marko.js ، لذا من الواضح أننا أخذنا هذه النتائج بحذر ، لكننا بذلنا قصارى جهدنا لنكون عادلين.

أيضًا ، أردت فقط إضافة بعض التعليقات الإضافية بخصوص Marko.js وسهولة الاستخدام:

لطالما سعى Marko إلى الحصول على أبسط تكامل مع Node.js. بعد تثبيت حزمة marko عبر npm ، ستجد هنا جميع الكودات المطلوبة لتقديم قالب إلى تدفق استجابة 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);

أعتقد أن هذا أمر بسيط مثل ما ستحصل عليه.

يعمل Marko أيضًا مع حزم وحدات JavaScript الشائعة: http://markojs.com/docs/bundler-integrations-overview/

لتقديم مكون Marko UI ذي المستوى الأعلى إلى DOM ، إليك كل ما هو مطلوب:

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 وفقًا لـ http://www.stefankrause.net/wp/؟p=431 المعايير ، markoJs
أداء مثل Vue et al.

لذلك ، يمكننا أن نستنتج أنه في البرمجة النصية من جانب العميل بشكل عام ، فإن Markojs و Vue متساويان في الأداء.

بالطبع ، المعيار ، الذي ربطته ، لا يشمل SSR. لذلك لن أعلق على ذلك.

أصوت لصالح Vue. يعد jQuery بالفعل متطلبًا قريبًا لاستخدام WordPress. يجب أن يشعر الأشخاص المطلعون على jQuery على دراية ببنية Vue. إنها أيديولوجية حول DOM ليست متطرفة مثل شيء مثل Angular. يعود إلى مبدأ WordPress في السهولة للمستخدم.

كما اقترحت منذ حوالي عامين لـ Calypso ، فإن استخدام Mithril.js لواجهة برمجة تطبيقات HyperScript سيكون خيارًا جيدًا لاستبدال React. لديها ترخيص MIT قياسي.

استثمار صغير في أدوات جديدة للقيام على الأقل ببعض الرفع الثقيل تلقائيًا للتحويل من React إلى مكتبة vdom أخرى قد يؤتي ثماره جيدًا في ساعات المطور المحفوظة - كما هو مذكور في هذه المشكلة كاقتراح لـ Automattic للقيام مسبقًا بالتحوط رهانها على React.

حتى بدون التفكير في مكتبات غير vdom ، هناك أكثر من 25 مكتبة vdom (على سبيل المثال ، inferno.js ، maquette ، إلخ) يمكن اعتبارها - كما في هذه القائمة التي جمعتها

فيما يلي بعض الأسباب التقنية التي تجعل Mithril.js أو واجهة برمجة تطبيقات HyperScript هي أفضل الخيارات.

أنا شخصياً أشعر بأن أساليب القوالب لإنشاء واجهات مستخدم مدعومة بـ JavaScript مثل React's JSX أو نهج Angular الخاص بالقالب أو أنظمة القوالب في العديد من أنظمة واجهة المستخدم الأخرى بما في ذلك Vue قد عفا عليها الزمن. لماذا ا؟ أصبحت التفضيلات و "أفضل الممارسات" لكتابة تطبيقات الويب المستندة إلى قالب HTML من جانب الخادم باستخدام أوراق أنماط CSS المعقدة (مثل مكونات WordPress الإضافية السابقة) "أسوأ الممارسات" لكتابة تطبيقات الويب ذات الصفحة الواحدة. تختلف الاحتياجات الفنية لكتابة تطبيقات العميل ذات الصفحة الواحدة المعقدة عن تلك الخاصة بالتعليمات البرمجية المستندة إلى الخادم بشكل أساسي بسبب التعقيد المتزايد في التعليمات البرمجية من جانب العميل. باختصار ، فإن "أفضل الممارسات" القديمة لاستخدام القوالب وأوراق الأنماط المتتالية المعقدة لا تتسع مما يؤدي إلى صعوبة الحفاظ على الكود.

ما هو البديل الناشئ؟ يمكن لتطبيقات الويب الحديثة استخدام Mithril + Tachyons + JavaScript / TypeScript لكتابة المكونات في ملفات فردية حيث تكون جميع التعليمات البرمجية عبارة عن JavaScript / TypeScript فقط. لا تحتاج هذه التطبيقات إلى أن تتم كتابتها جزئيًا إما في CSS أو بعض المتغيرات غير القياسية من HTML التي تعيد تنفيذ جزء من لغة البرمجة (بشكل سيء). (حسنًا ، قد يكون هناك قدر ضئيل جدًا من CSS المخصص المطلوب فوق Tachyons أو المكتبات المماثلة ، ولكن القليل جدًا.)

فيما يلي مثال لملعب الترميز الذي كتبته بهذه الطريقة مع العديد من الأمثلة التي تستخدم هذا النهج.

لذلك ، من خلال كتابة واجهات المستخدم باستخدام HyperScript (بالإضافة إلى مكتبة vdom) ، يمكنك (مع بعض الأعمال) استبدال الواجهة الخلفية مثل Mithril بأي نظام vdom آخر تقريبًا أو حتى حل غير vdom. لذلك ، عندما يكون لدي خيار ، فإن اختيار استخدام HyperScript API هو طريقة لتخفيف المخاطر من المكتبات الأساسية التي بها أخطاء أو مشاكل في الترخيص.

باستخدام Tachyons أو مكتبات مماثلة ، أقوم بتخفيف مخاطر ملفات CSS غير القابلة للاستمرار مع نمو التطبيق.

من المؤكد أنني أعلم أن العديد من مطوري الويب نشأوا على التغيير والتبديل في HTML ويحبون القوالب ذات المظهر HTML. لذلك ، فهم يحبون JSX أو أيًا كان ، ويسعدهم تجاهل مدى صعوبة إعادة تشكيل مثل هذه الأشياء غير البرمجية في منتصف تطبيقاتهم أو التحقق من صحتها. من المؤكد أن بعض IDEs تتحسن في إعادة هيكلة قوالب JSX. لكنني جئت إلى تطوير الويب من تطوير سطح المكتب والتطوير المضمن بالعمل مع أنظمة حيث (عادةً) تقوم بإنشاء واجهات مستخدم مباشرة من التعليمات البرمجية (على سبيل المثال باستخدام Swing و Tk و wxWidgets وما إلى ذلك). تعجبني فكرة أن الأدوات القياسية يمكن أن تساعدني في إعادة تشكيل جميع الكودات التي أعمل عليها واكتشاف العديد من التناقضات.

بافتراض أن جميع الأطر قيد التشغيل هنا لا تحتوي على أي اختلافات واضحة للمستخدم بسبب سرعتها في المتصفح الذي يختاره ، يمكننا التوقف عن استخدام أداء الواجهة الأمامية كمقياس لتقييم أي إطار هو الخيار الأفضل.

ولكن إذا استخدمنا عرض جانب الخادم ، فيجب أن ننظر بعناية إلى أداء SSR. يبدو أن كاليبسو تهدف إلى الحصول على SSR. وإذا نجحت ، فستقوم شركة Calypso يومًا ما بتشغيل معظم المواقع على wordpress.com.

تدفع الشركة مقابل وحدة المعالجة المركزية على الخوادم ، وليس وحدة المعالجة المركزية على المتصفحات. لذا من منظور التكلفة ، من المحتمل أن يعني

إذا كان بإمكان Wordpress تجاهل ذلك ، فسأحضر بكل سرور للعمل في الشركة وأحصل على راتب سوق 10x واستخدام Vue ، بالمناسبة ، أعتقد أنه بديل جيد لـ React =)

كلما كان إطار العمل أخف - أي كلما قلت الوظائف التي يقدمها خارج الصندوق - كلما كان أداءه أسرع. إنه واضح بشكل مثير للشفقة. إن مقارنة أداء الخوارزميات المختلفة أمر واحد ، ولكن عندما يكون العامل الأكبر هو مقدار "الأشياء" الأخرى التي يتم إجراؤها ، فلن تحتاج إلى كتابة الاختبارات.

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

ahmadawais فريق Angular الأساسي هنا - نحن في تقدم في الكثير من الأعمال المثيرة للاهتمام المتعلقة بتطوير نمط CMS / Widget ، بما في ذلك الاستثمار في دعم Custom Elements (والذي ، بالنسبة لأموالي ، هو الرهان المستقبلي الذكي لبناء المنصات)

بدلاً من تشويش سلسلة المحادثات بشكل أكبر ، يسعدنا التحدث معك في وضع عدم الاتصال ، إذا كان لديك أي اهتمام. مراسلتي على robwormald في google dot com. حظًا سعيدًا في هذا الأمر ، لا أحسدك على إجراء هذه المكالمة ؛-)

لقد أجريت استطلاعًا بسيطًا هنا والذي يمكن استخدامه للحصول على نظرة ثاقبة لما يريده الناس ..

تعمل حاليًا على صفحة النتائج والمصادقة عليها. (جديد في Firebase)

ملاحظة. استغرق الأمر حوالي ساعة واحدة لإجراء ذلك باستخدام Vue 🖖

vinayakkulkarni ماذا عن إضافة Mithril.js إلى استطلاع الرأي الخاص بك؟

pdfernhout : 👍

منجز. لقد أضفت MithrilJS إلى القائمة.

• [x] VueJS
• [x] الزاوي
• [x] preact
• [x] إمبر
• [x] ماركو
• [x] الجحيم
• [x] أوريليا
• [x] ميتريل

دعونا نرى ما يقرره الناس ..
ملاحظة. كان هناك استطلاع على تويتر بواسطة ahmadawais أيضًا.

مرحبا. أنا مشرف دروبال كور. كما ذكر ivanjaros في تعليق سابق ، نقوم أيضًا بتقييم Preact أو Vue أو أي شيء آخر ، لبعض الأجزاء القادمة من واجهة مستخدم مشرف Drupal. قد نستقر على شيء مختلف عما تختاره ، ولكن ما تختاره سيكون بالتأكيد عاملًا واحدًا على الأقل بالنسبة لنا في اختيارنا.

لقد فتحت هاتين القضيتين دروبال حتى الآن ، وسيأتي المزيد. ما عليك سوى الرجوع إليها هنا في حال كانت تلك القضايا / المناقشات مفيدة لك.

• مكونات إرجاع عقد جذر متعددة
• فتحات مقابل الدعائم vnode

لاحظ أنني ما زلت أحب Vue بشدة ، على الرغم من هاتين المسألتين. قد تكون هذه أشياء لا بأس في التعايش معها ، من أجل الحصول على جميع الفوائد الأخرى لـ Vue.

بصفتي مؤلف Vue ، سأتجنب الإدلاء بأي تعليقات بخصوص إطار العمل الذي يجب اختياره هنا لأنني من الواضح أنني متحيز ؛ ولكن كما رأيت العبارة القائلة بأن "Marko أسرع بـ 10x من Vue" تم طرحه عدة مرات ، أشعر أنه يستحق بعض الإيضاح. كما أنني لا أريد تحويل المناقشة عن مسارها إلى نقاش تقني ، لذلك قمت بتدوين بعض الأفكار في هذا الجوهر لأولئك المهتمين.

@ michaelbdavidson7 فيما يتعلق بالمخاوف المالية: لقد كنت أعمل على Vue بدوام كامل لأكثر من 1.5 عامًا حتى الآن وكان دعم Patreon مستقرًا حقًا. بدلاً من التكهن بشأن تقلبات تعهدات Patreon ، يمكنك التحقق من نشاط الالتزام في Vue للحكم بنفسك. بالإضافة إلى ذلك: إن وجود قناة مساهمة مالية مفتوحة يعني أن WP / Automattic يمكنها بسهولة ضمان استدامة Vue من خلال أن تصبح راعًا رئيسيًا (مات نفسه هو بالفعل راعي شخصي!) - وهذا يتوافق بالفعل مع مصالح كلا المشروعين

أصوت Vuejs

@ tungbt94 لماذا؟

بالتأكيد VueJS

السؤال الأكبر ، لماذا تم اختيار رد الفعل قبل قضية البراءة هذه. إذا لم تكن براءة اختراع ، فهل ستستمر في استخدام رد الفعل؟ الكثير من النقاط التي تم طرحها حول عدم اختيار ما قبل التصرف هي نفسها عدم اختيار رد الفعل.

تصويتي مع Preact

نظرًا لأنني لا أمتلك خبرة كبيرة في أي شيء آخر غير React ، فلن أثقل في إطار العمل الذي سأختاره.
ومع ذلك ، أعتقد أن حجة "المجتمع الكبير" يمكن أن تكون أقل أهمية. لماذا ا؟ لأنه عندما يقرر Automattic إطار عمل ، فإن هذا العمل الزراعي سيحصل على آلاف المستخدمين الجدد. وإذا علمت أن مجتمع WP صحيح ، فسيبدأ العديد منهم في المساهمة في هذا الإطار أيضًا وسترتفع الشعبية.

بالنظر إلى مكان وجود جوتنبرج وكاليبسو في الوقت الحالي ، ما زلت أعتقد أن Preact هو أفضل خيار هندسي.

ومع ذلك ، إذا كنت لا تزال تشعر بالقوة حيال حرق الجسور بأي تشابه مع React أو إذا كان عليك أن تبدأ من الصفر ، ما زلت أعتقد أن MarkoJs هو الخيار الأفضل. أعتقد أن دعم المجتمع قد لا يزال مصدر قلق.

بافتراض أن نجوم Github مرتبطون بطريقة ما بالمجتمع ، فإن Vue لا يزال 10x مقارنةً بـ MarkoJs ولكن بالنظر إلى الرسوم البيانية سيتغير بسرعة.

ينمو Vue خطيًا:

لكن يبدو أن MarkoJs على نقطة انعطاف للنمو الأسي:

@ patrick-steele-idem ، المؤلف الرئيسي لـ MarkoJs ، كان دائمًا https://gitter.im/marko-js/marko

عندما يختار الناس MarkoJs في النهاية ، ولكن حقًا أي نوع من المجتمع ، أشعر

أنا شخصياً أود أن أهنئ ahmadawais على إنشاء مشكلة واحدة خلقت مشاركة كبيرة من العديد من مطوري JS الذين يستخدمون ويدعمون خيارات مكتبة JS ذات الصلة

أظن أن هذه المشكلة قد ساعدت في إعلام المزيد من JS Devs حول تحركات WordPress نحو المزيد من التطوير المستند إلى JavaScript عبر Gutenberg أكثر من أي اتصال Gutenberg آخر حتى الآن.

أستخدم AngularJS ولكن ما لا يعجبني هو التحديث الرئيسي في كل مرة ، لذلك سأختار VueJS.

+1 لماركو. مكتبة رائعة يستخدمها فريقنا وكان سعيدًا جدًا بها. التقديم غير المتزامن ، سريع للغاية (يتم عرضه على السلسلة في الخادم وإلى vdom في المستعرض) ، ومكونات فردية أو متعددة الملفات ، وأفضل صيغة للقوالب موجودة في IMO.

يرجى أخذ hyperHTML الخاص بـ WebReflection في الاعتبار.

أنا أحب Angular

أنا أصوت Angular

اخترت الزاوي

فقط الزاوي

اخترت الزاوي

الزاوي

أنا أصوت Angular

أنا أصوت Angular

إذا كنت ترغب في التصويت لإطار عمل ، فسيكون من الجيد معرفة السبب الدقيق وكيف يساعد جوتنبرج.

إلى الزملاء الذين يأتون إلى هنا ليقولوا "أنا أصوت لـ X" ، يرجى إعطائنا بعض الأسباب التي تجعلنا نصوت X أيضًا. "أنا أصوت X" لا تخبرنا شيئًا سوى أنك تحب X.

أختار الزاوي. Angular لها بعض التغيير الكبير منذ الإصدار 2. الآن ، إنه جيد تمامًا - إطار مستخدم قويًا وعلى نطاق واسع - لأنه ، مثل الأيوني ، لا يدرس بسرعة ، ولكن بقوة.

مع وجود الكثير من الرسائل غير المرغوب فيها "أنا أصوتإطار "، جيثب يصرخ من أجلي.

أحث زملائي المطورين على التفضل بالتصويت على اختيارك لإطار العمل على https://vinayakkulkarni.github.io/poll/ https://vinayakkulkarni.github.io/poll/ بدلاً من مجرد نشر "أصوت ...

هناك اقتراح آخر وهو قفل هذه المحادثة ؛ كان لدى معظم المطورين الرئيسيين رأيهم في هذا الأمر.

في 18 سبتمبر 2017 الساعة 8:01 مساءً ، كتب Mingyue [email protected] :

أختار الزاوي. Angular لها بعض التغيير الكبير منذ الإصدار 2. الآن ، إنه جيد تمامًا - إطار مستخدم قويًا وعلى نطاق واسع - لأنه ، مثل الأيوني ، لا يدرس بسرعة ، ولكن بقوة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/WordPress/gutenberg/issues/2733#issuecomment-330241898 ، أو تجاهل الموضوع https://github.com/notifications/unsubscribe-auth/AS3FbT23DvVwTLGL61tmK7KtuwZeg- ucks5sjn7SgaJpZM4PYie9 .

شكرًا kidwm على ذكر _hyperHTML_ ، لكن أعتقد أنه من الأفضل اتباع توجيهاتهم:

لا تشارك فقط إطار عمل JS الذي يعجبك ولكن أيضًا تشارك السبب

لذا اسمحوا لي أن أحاول القيام بذلك ...

: zap: hyperHTML :

• PRO : المبتدئين ودودون ومألوفون لمستخدمي P / React (بدلاً من JSX ، تكتب Template Literals)
• PRO : اشتعلت فيه النيران بسرعة وبدون VDOM ؛ استهلاك أقل للذاكرة (الأسواق الناشئة صديقة للهواتف)
• PRO : لا يتطلب أي أدوات (يتطلب قوالب حرفية مترجمة فقط لـ IE <11)
• PRO : يعتمد بالكامل على معايير JS / DOM / HTML ولكنه متوافق أيضًا مع TypeScript
• PRO : يناسب أقل من 5 كيلو بايت (min-zip) دون الحاجة إلى polyfills إضافية أو تصحيحات المتصفحات
• PRO : تغطية الكود بنسبة 100٪ وصولاً إلى المراوغات IE9
• PRO : يشارك نفس API مع نظيره NodeJS ؛ 100٪ من جانب الخادم متوافق
• PRO : يمكنه اعتماد DOM الموجود دون التخلص من تخطيطات / عقد SSR
• PRO : يعمل مع العناصر المخصصة بشكل أفضل من P / React ، ويمكن استخدامه أيضًا لتحديد العناصر المخصصة
• PRO: يمكن أن تفعل ما تتفاعل ، Vue.js ، البوليمرات ، الزاوي ، أو ماركو به، ويفوز من حيث الحجم / عرض النطاق الترددي / كل منهم أداء

الآن ، وفقًا للمقاييس المستخدمة حتى الآن في هذا الموضوع ، فإن CONS

• العيوب : حتى لو تم اختباره في المعركة ، وتم تغطيته بالكامل ، ومع واجهة برمجة تطبيقات مجمدة ، فهو مشروع صغير نسبيًا (مارس 2017) لذلك لا يمكنه المنافسة من حيث الشعبية أو التبني أو عدد المساهمين
• العيوب : يساعد المجتمع كثيرًا والمشروع ينمو ، ولكن أنا المساهم الفني الرئيسي حتى الآن. أنا ملتزم 100٪ بهذا المشروع ، وأرغب في دفعه قدر المستطاع ، بالإضافة إلى أنني أناقش مع عدد قليل من "_bigs_" حول استخدام _hyperHTML_ في بعض المشاريع الكبيرة التالية منها (لن أتوقع المزيد على الرغم من ذلك لا تتردد في تجاهل هذا الجزء الأخير)

: dart: أعتقد حقًا أن مستقبل الويب هو استخدام النظام الأساسي قدر الإمكان ، وهو بالتأكيد أفضل بطريقة أفضل مما كان عليه قبل 10 سنوات ، وبفضل مواصفات ECMAScript الحديثة أسهل في الكتابة والقراءة والصيانة. _hyperHTML_ يمثل "_الحالة الحالية لفن الويب_" من حيث الإمكانات ، بينما ولد كل متنافس آخر في هذه القائمة في عصر ما قبل ES6 الكامل.

أدرك أهمية حجم المجتمع والمساهمين ونجوم GitHub ، ولكن أعتقد أنه يجب أيضًا مراعاة الاختبارات وتغطية الشفرة عبر المتصفح ومقدار الأخطاء ، وأنا أبذل قصارى جهدي للحفاظ على عدد _ hyperHTML_ والأصدقاء المقربين من صفر (هو في الواقع صفر الآن ، بجانب مناقشة ليست خطأ).

أخيرًا وليس آخرًا ، إذا لم يمنح أحد الحلول الجديدة فرصة والحكم فقط من خلال النجوم والضجيج ، فستستغرق الحلول الجديدة وقتًا أطول مما ينبغي لتصبح أكثر شيوعًا.

بالطبع ، لقد تحدثت عن الحل الأخير الذي قدمته ، قد يتم اعتبار اعتباراتي ذاتية ، ولكن بشكل خاص جملتي الأخيرة حول إعطاء فرصة لحلول جديدة ، كانت عامة جدًا ، وليس فقط حول مكتباتي: مبتسم:

تحياتي الحارة

أنا أحب الزاوي

يجب أن يكون الزاوي و google.

احب الزاوي

Angular هو إطار حقيقي فقط!

اخترت Angular ، وليس AngularJs.

الزاوي فقط هو إطار حقيقي!

بدأت في الشك ، هذه التعليقات من صنع الروبوتات.

OP : الرجاء قفل هذا الموضوع.

أصوت لصالح Angular (NOT AngularJS).

Angular عبارة عن مسطح ، يقوم فريق Google بالكثير من العمل الرائع لجعل تقدم التطوير أسهل ، بما في ذلك المكون والوحدة والموجه ، مع حقن التبعية ، يمكنك توفير الكثير من العمل لترتيب كل التبعية ، باستخدام زاوية cli ، يمكنك توفير الكثير من العمل لبدء مشروع جديد تمامًا ، ما عليك سوى فتح الصندوق ويتم تجميع تطبيقك جيدًا باستخدام aot ، وهز الشجرة ، والعديد من التحسينات الأخرى.

TypeScript هي أداة رائعة أخرى ذات زاوية ، يتم توفيرها بواسطة MicroSoft ، ويعرف أيضًا باسم النظام الأساسي الزاوي بالكامل ، والذي تم تصميمه باستخدام ts. أنت تبني تطبيقك باستخدام ts أيضًا! إنها أداة رائعة لجعل الحياة أسهل عندما يزداد حجم الكود ويزداد حجمه ، يمكنك القيام بإعادة البناء في IDE (مثل vscode) بنقرة واحدة فقط. يجعلك فحص النوع الثابت من العثور على الأخطاء في أقرب وقت ممكن. يوفر TS أيضًا تنفيذًا جيدًا لـ OOP ، يمكنك ترتيب وإعادة استخدام الكود الخاص بك بطريقة أفضل بكثير.

هناك أيضًا الكثير من المكونات المبنية على أساس الزاوي ، مثل التصميم المتري 2 ، و primeng ، وأريد أن أوصيك بـ Jigsaw ، الذي تم إنشاؤه بواسطة فريقنا. تم تبنيه من قبل منتج البيانات الكبيرة من ZTE الصين. إنه يدعم جميع تطبيقات ZTE الآن.

Anglar هو خيار رائع !!

لجميع الروبوتات: 🖕

ربما نشر شخص ما في مجتمع AngularJs. أعتقد أنه يمكن للأشخاص كتم صوت الموضوع إذا كانوا لا يريدون تلقي المزيد من الرسائل.

أعتقد أنه في النهاية يجب أن تتم محادثة مماثلة حول هذا الموضوع في مكان لا يوجد فيه سوى مساهمين في WordPress.

أرغب في مشاركة بعض أفكاري حول هذه المشكلة التي عبرت عنها في الغالب بالفعل في مجموعة مجتمع EmberJS Slack ، إذا كان لديك 10 دقائق لقراءة المناقشة هناك ، فإنني أوصي به: https://embercommunity.slackarchive.io / wb-marketing / page-2 / ts-1505456102000189 يوجد الكثير جدًا ولكني أوصي بشدة

النقاط الرئيسية في هذا النقاش هي كما يلي:

• عند مقارنة ارتفاع مدته 2-4 أسابيع في تنفيذ شيء ما في إطار Ember مقابل أي مكتبة أخرى ، تميل المكتبات الأخرى إلى الفوز على المدى القصير ، لكن Ember يفوز في أي مشروع طويل المدى
• عند التفكير في أي مكتبة أو إطار عمل يتماشى معه ، من المهم ليس فقط مراعاة التنفيذ الفني ولكن أيضًا جوانب "المهارات الشخصية" (حجم المجتمع ، والالتزام بدعم LTS ، ومشاركة المجتمع في القرارات الأساسية للمشروع)
• تتمتع Ember بسجل حافل في تقديم تحسينات كبيرة للتطبيقات التي تم إنشاؤها باستخدام ember-cli "تحت الغطاء" ، أي دون الحاجة إلى ترقية أي من كود التطبيق. كانت هناك أيضًا حالات من الترقيات الطفيفة لرمز التطبيق (مع تضمين كود التعديل باستخدام أشياء مثل ember-watson ) تحصل على أداء كبير وزيادة في الإنتاجية.

لا أريد الخوض في الكثير من التفاصيل في هذا التعليق لأنني أستطيع أن أكتب مقالًا يضم 10000 كلمة عن النقاط المذكورة أعلاه. ومع ذلك ، أود أن أقدم وقتي لأي شخص يرغب في مناقشة هذه المسألة مع شخص لديه "عقلية إمبر".

إذا رغب أي شخص من صانعي القرار في إجراء مكالمة معي لمدة ساعة لطرح المزيد من الأسئلة المحددة حول نظام Ember البيئي الأوسع ، فسأقوم بذلك بكل سرور. يمكنك التواصل معي على Twitter (DMs open) قد لا أكون عضوًا أساسيًا في الفريق ، لكنني كنت أقوم بإنشاء تطبيقات Ember منذ ما قبل الإصدار 1.0 وخضعت لجميع عمليات الترقية باستخدام تطبيقات مختلفة

أعمل في "My eBay" في eBay. لقد أطلقنا للتو أول تطبيق من صفحة واحدة . لقد استمتعنا بكل مرحلة من مراحل التطوير باستخدام MarkoJS. مثلي إذا كنت تحب نموذج برمجة تدفق العقدة ، فإن MarkoJS يدعم البث والعرض غير المتزامن. حقائق أخرى أعجبتني حول MarkoJS:

• الارتباط الفعال لسلوك مكونات واجهة المستخدم التي يتم عرضها على الخادم والمتصفح.

• تفويض حدث فعال للغاية

• تسلسل سريع للحالة من الخادم إلى المتصفح

vinayakkulkarni أعتقد أن فكرتك جيدة ، لكن المشكلة هي أنه يمكنني ترك أكثر من صوت واحد عن طريق تغيير المتصفح (لم أحاول باستخدام نفس المتصفح).

ربما يجب عليك استخدام استطلاع Twitter (ولكن هناك واحد بالفعل) أو تطبيق نظام تسجيل الدخول لجعل الأصوات فريدة.

عرض الخادم غير ذي صلة بالمحادثة هنا. لن تصبح العقدة جزءًا من حزمة WordPress المطلوبة ، لذا فإن سرعة عرض هذه الأطر في Node ليست ذات صلة بالقرار.

Vue.js! انظر إلى هذا المشروع https://github.com/bstavroulakis/vue-wordpress-pwa

اخترت Angular (وليس AngularJS) ، فهي تضم أكبر مجتمع ، ونظام بيئي مستقر وكامل.

Angular بطيء جدًا ومع الإصدار 4 الذي يعتمد على الكتابة المطبوعة ، فإنه غير مفيد لتطوير Wordpress ..

اخترت Angular حسب نضج المنصة

سأصوت لصالح Vue لأنه من الأسهل التعلم ولأن إطار العمل المفضل لدي Ember Js كبير جدًا بالنسبة للوظيفة ولا يزال Glimmer Js جديدًا جدًا. :-)

عرض الخادم غير ذي صلة بالمحادثة هنا.

في حالتي ، أشرت للتو ميزة يعتقد الآخرون أنها ذات صلة

لن تصبح العقدة جزءًا من حزمة WordPress المطلوبة

_hyperHTML_ يمكنه التقاط أي محتوى معروض من جانب الخادم ، بما في ذلك PHP. أنا مهندس معتمد من Zend ، وعملت مع صحفيين / ناشرين باستخدام WordPress بالفعل ، ولم يكن تلميحي مجرد شيء.

لذا فإن سرعة عرض هذه الأطر في Node ليست ذات صلة بالقرار.

حقيقة أن إطار العمل يعمل على الواجهة الخلفية أيضًا ، يمكنه التقاط المحتوى المعروض من جانب الخادم ، وسيكون متوافقًا مع NativeScript ربما يكون ميزة إضافية غير ذات صلة اليوم ، ولكن مستقبلًا متوافقًا مع ميزة جيدة ، كما قد يفكر فيه مشروع منفتح.

@ webreflection لم أقصد هذا التعليق

رأي

mAAdhaTTah من https://ma.tt/2017/09/on-react-and-wordpress/ :

لن يتم نشر هذا المنشور ، وبدلاً من ذلك أنا هنا لأقول إن فريق جوتنبرج سيتراجع خطوة إلى الوراء ويعيد كتابة جوتنبرج باستخدام مكتبة مختلفة. من المحتمل أن يؤخر Gutenberg بضعة أسابيع على الأقل ، وقد يدفع الإصدار إلى العام المقبل.

والأهم:

سيستخدم Automattic أيضًا كل ما نختاره لـ Gutenberg لإعادة كتابة Calypso

يستخدم Calypso بالفعل عرض جانب الخادم. انظر: https://github.com/Automattic/wp-calypso/blob/master/server/render/index.js#L58

لذا فهمت أن أداء إصلاح القطاع الأمني ​​(SSR) وثيق الصلة.

أنا أحب الزاوي أيضًا！
إطار العمل الحقيقي AngularJS js！

أصوت لصالح Angular

chriscinelli هذا

من الواضح أن Angular هو الخيار الأفضل

أصوت لصالح Angular

أصوت لصالح Angular

أصوت لصالح Vue.js.
إنه يوفر معظم الوقت ، خاصة عند التعامل مع طبقة العرض.

يجب أن أصوت لصالح Vue !!!

يلقي موجة من الزاوي

@ trotyl هذا التعليق غير مقبول. لقد قمت بتحرير تعليقك لإزالته.

أوه ، من فضلك لا AngularJS
الآن هو الزاوي.

mAAdhaTTah من ويكيبيديا:

تم إصدار WordPress في 27 مايو 2003 من قبل مؤسسيه ، Matt Mullenweg و Mike Little كشوكة من b2 / cafelog

على الرغم من تطويره إلى حد كبير من قبل المجتمع المحيط به ، فإن WordPress يرتبط ارتباطًا وثيقًا بشركة Automattic ، التي أسسها Matt Mullenweg.

هذا هو Calypso: https://developer.wordpress.com/calypso/ ويستخدم Calypso SSR.

كما كتبت في تعليقي السابق ، من الواضح تمامًا من منشور المدونة الذي

أعتقد أن هذا كافٍ لجعل أداء SSR وثيق الصلة بهذا القرار.

ولكن في المستقبل البعيد ، بمجرد أن يعتاد مطورو Wordpress على Preact (أو Vue أو Marko أو إطار عمل آخر) ، قد يظهر مشروع مجنون جديد ويقررون خدمة أجزاء أكثر من Wordpress من خلال العقدة. هذا سيجعل SSR أكثر أهمية. لذلك قد يكون أداء SSR أكثر أهمية.

مع تقدم المحادثة لمناقشة SSR ، أعتقد أنه من الحكمة أن أذكر أن هذا يمثل أولوية عالية جدًا لـ Ember وقد تم التفكير فيه على نطاق واسع مع ظهور Ember-Fastboot

بينما أستخدم Fastboot (لتأثير كبير) مع عدد قليل من تطبيقات العميل لأن هذه مناقشة تقنية عالية المستوى ، أوصي بالتواصل مع tomdale حيث كان بطل جهود Fastboot

chriscinelli WordPress لا يزال مشروع المجتمع و Automattic الشركة كيانين منفصلين. إذا أرادت شركة Automattic أن تجادل لصالح واحد أو آخر بسبب SSR ، فيمكنهم ذلك ، ولكن لا يزال لا يغير الطريقة التي ينبغي لنا ، نحن مجتمع WordPress ، النظر في إطار العمل المختار لنواة WordPress ، والذي لا يفعل ، ولا يمكنه فعلاً ، تتطلب عقدة للتشغيل.

على أي حال ، لقد ألغيت اشتراكي من هذا الموضوع. إذا كنت ترغب في متابعة هذه المناقشة في وضع عدم الاتصال ، فإن بريدي الإلكتروني موجود في ملفي الشخصي.

لا تتطلب عقدة لتشغيلها ، ولا يمكنها ذلك.

من فضلك لا تجعل قدرة SSR نقطة تمييز. يمكن أن تعيش الأطر القادرة على عقد SSR بدون أي عقدة SSR على الإطلاق: إنها مجرد ميزة إضافية ، وليست مطلبًا ، ولا تبعية.

سأصوت لصالح Vue.js

لقد ذهبت إلى معهد ماساتشوستس للتكنولوجيا ومن المفترض أن أكون ذكيًا بشكل معقول. لقد كنت أفعل هذا لسنوات عديدة وأجريت مقابلات مع عدد قليل من المطورين هنا وهناك. أعلم أن الويب مليء بالأشخاص الأذكياء ، لكن أي شخص يعتقد أن بساطة Vue تتساوى مع تعقيد Angular فقد ​​منظورًا لما يشكل "معقدًا". Javascript القائمة على المكونات ، كما تصورتها Google ، ليست تافهة تمامًا. إنه معقد بشكل يبعث على السخرية. Vue ليس كذلك. Vue سهل مثل PHP. أقول ما هو واضح ، لأن "Vue أسهل في التعلم" لا تقترب حتى من وصف مدى سهولة Vue من Angular. وهنا تكمن المشكلة - أعتقد أنها أيضًا أسهل بكثير من React.

كانت React تسير في الخط الفاصل بين easy-peasy ومستوى google ، بالنسبة للأشخاص العاديين. بالنسبة إلى المتاجر الصغيرة ، أود أن أقول إن React معقدة بما يكفي لتحدي الفرق الصغيرة. React أكثر تعقيدًا من PHP / Wordpress على سبيل المثال. باختيار React ، رفع Wordpress / Automattic متطلبات دخول المطور إلى عالم مطوري Wordpress. أنا متأكد من أن مئات الأشخاص سيصرخون ، "React سهلة" و "الويب تزداد ذكاءً" ، لكن الأكثر تعقيدًا لا يزال أكثر تعقيدًا ، في نهاية اليوم.

أعتقد بتواضع أن العودة إلى Vue سيكون أقرب إلى جذور WP ، وأقل من العبء الفني على مجتمع WP ككل. بغض النظر عن نماذج الويب - أحيانًا يكون البساطة أمرًا جيدًا.

Angular و Vue هما شيئان مختلفان

Vue و React و MarkoJS و Inferno و Preact وغيرها هي مكتبات تغطي طبقة العرض فقط. كل منهم بما في ذلك Angular لديهم طريقة لإنشاء HTML وتعديل DOM بطريقة تعريفية. يريد Angular توفير إطار عمل كامل لتطوير الواجهة الأمامية ولديه الكثير من الأشياء خارج طبقة العرض.

صيغة React هي الأقدم في هذه العينة. قام Facebook بعمل جيد جدًا لربط مكتبة معقدة للغاية تقوم بالكثير من الأشياء (ربما كثيرة جدًا) في سطح بروتوكول محدود للغاية. لا تحتاج إلى معرفة أي من هذا التعقيد داخل React لتعرف كيفية استخدامها وتكون منتجًا معها. يمكنك التعرف على الأساسيات والبدء في استخدامها في نصف يوم.

تعلمت كل مكتبة أخرى في هذه القائمة من React. لقد حاولوا تبسيط بناء الجملة ، وتحسين أداء React ، وتقليل حجم شفرة Javascript اللازمة للقيام بنفس الأشياء وإضافة بعض الميزات فوقها.
قام Preact بعمل رائع للحفاظ على واجهة مشابهة جدًا لـ React في 3 كيلوبايت فقط.
قام Inferno و Marko بتحسين أداء العرض بشكل كبير.
قام Marko و Vue بتبسيط بناء الجملة كثيرًا لتقليل الشفرة المعيارية.
أضاف Marko أيضًا بناء جملة اختياريًا مثل Jade / Pug للحفاظ على الشفرة أكثر جفافاً والقدرة على إنشاء قوالب غير متزامنة تجعل كل شيء بسيطًا وبديهيًا للمستخدم.

ومع ذلك ، فإن كل هذه المكتبات بجانب Angular تتطلب من المهندسين أن يخرجوا بإستراتيجية وآليات لجلب البيانات ، والتوجيه ، وما إلى ذلك. تعد Redux وأدواتها الوسيطة إحدى الطرق الشائعة التي استخدمها Gutemberg لإدارة طبقة البيانات.

في الترحيل من React ، لا يحتاج Gutenberg "مجرد شيء آخر لتغييره". حتى لو سعى Angular لإبقاء نفسه حياديًا للمستخدم ، فإن استخدامه مع Redux و Javascript (مقابل Typescript) ليس خيارًا طبيعيًا على الرغم من أن المكتبات مثل https://github.com/angular-redux/ng-redux تم تطويرها ودعمها لجافا سكريبت متاح. علاوة على ذلك ، بالنظر إلى الأصوات حتى الآن ، يبدو أن مجتمع Gutenberg يعارض بشدة إطار عمل Google. لذلك على الأرجح لن يكون Angular خيارًا.

PHP وأي من إطارات عمل Javascript هي وحوش مختلفة تمامًا

يمكن أن يكون لديك واجهة PHP خلفية وواجهة تطبيق صفحة واحدة ولكن لا يوجد تآزر وقليل من أوجه التشابه.

أي تطبيق Javascript هو ترتيب واحد على الأقل من التعقيد أعلى مما يمكنك كتابة كود PHP عادي مرشوشة ببعض jQuery. جميع تطبيقات جافا سكريبت الحديثة أن تتعامل مع اثنين من وحوش تعقيد كبيرة: statefulness والتدفقات غير متزامن. يتم تخفيفها فقط عن طريق الثبات و async / await في هذه السنوات الماضية. يتباطأ تدفق المطورين مع نمو التطبيق. عندما تقوم بتغيير بعض التعليمات البرمجية ، فأنت بحاجة إلى إعادة الترجمة ، وأعد التشغيل ويجب أن يمر التطبيق بعملية التهيئة مرة أخرى. تم إنشاء كمية هائلة من الأدوات لتنفيذ عمليات إعادة التحميل الساخنة ، وحتى لو كانت رائعة ، فإنها لا تزال بعيدة عن الكمال.
بغض النظر عن المكتبة التي تختارها لطبقة العرض ، سيكون عليك التعامل مع التعقيد الإضافي.

في PHP ، تقوم بتغيير الكود ، وتحفظ ملفًا ويمكنك إعادة تحميل الصفحة على الفور بدون إنشاء أو إعادة تحميل. كل شيء يعمل. والأهم من ذلك أن PHP عديمة الحالة تمامًا. في كل مرة تقوم فيها بإعادة تحميل الصفحة ، يكون لديك قائمة فارغة. حتى المتغيرات العالمية لها حالة نظيفة مع كل طلب (ولكن ليس عذرًا جيدًا لاستخدامها = P). لم أكتب كود PHP في غضون سنوات قليلة ولكني ما زلت أفتقد بساطته وتجربة المطورين. إذا كنت تستخدم إطارًا حديثًا مثل CakePHP أو Symphony أو Laravel ، فلن يفوتك الكثير مقارنة باللغات والأطر الأخرى التي يرحب بها المهندسون المتمرسون أكثر. الاستثناء هو السرعة. تدفع PHP بساطتها من خلال أداء وقت التشغيل. في كل مرة تقوم فيها بإعادة تحميل صفحة ، يجب تنفيذ جميع التعليمات البرمجية مرة أخرى. زاد الأداء كثيرًا مع HHVM و PHP7 ولكن بشكل عام لا يزالان بعيدًا عن ما يمكنك تحقيقه باستخدام node.js.

استنتاج

لا يهم المكتبة التي استخدمتها مؤخرًا للواجهة الأمامية. حتى لو كنت تحبها ، فهذا لا يعني أنها الخيار الأفضل لجوتنبرج.
ومع ذلك ، فإن حقيقة أن _ معظم المساهمين الأساسيين في Gutenberg_ قد يحبون مكتبة واحدة محددة أمر مهم.

فى النهاية:

لا يزال الرجل مقتنعًا ضد إرادته من الرأي نفسه

أعتقد أن هناك قدرًا كبيرًا من المعلومات حول هذا الموضوع حول إيجابيات وسلبيات المكتبات المختلفة القابلة للحياة.

يجب ترك مساهمي Gutenberg و Wordpress وحدهم قد يجتمعون في "أبواب مغلقة" ، بعيدًا عن المعجبين في الواجهة الأمامية.
قد يكون الوقت قد حان لتوضيح قيمك وأهدافك وقيودك واختيار إطار العمل بناءً على ما يزيد من نتائجك.

ونتمنى لك التوفيق مرة أخرى بقرارك 😃

أدليت بصوتي لصالح Vue. صديقة للمبتدئين وقوية. عندما بدأت استخدام Vue لأول مرة ، شعرت بهذا الشعور عندما بدأت في التطوير باستخدام WordPress. + 💯

@ النغمات الملونة فقط ودية للمبتدئين ليست جيدة بما فيه الكفاية! كل مشروع لديه دورة حياة ، ومعظم العمل في تقدم الصيانة.

ChrisCinelli بعض التوضيحات والآراء:

يريد Angular توفير إطار عمل كامل لتطوير الواجهة الأمامية ولديه الكثير من الأشياء خارج طبقة العرض.

يحتوي Vue على مكتبات رسمية للتوجيه وإدارة الحالة والاختبار والفحص والمزيد ، بالإضافة إلى أداة cli الرسمية. كل هؤلاء يخضعون لمنظمة vuejs ، ويحتفظ بهم الأعضاء الأساسيون ويظلون متزامنين مع Vue نفسها ، ولكن أفضل جزء هو أنك لست بحاجة إلى تعلمها أو استخدامها (ومن هنا جاءت فلسفة "الإطار التقدمي"). على عكس React ، فإن هذا يجعلها بشكل فعال إطار عمل في شكلها الرسمي. لعبة الكلمات الصغيرة: كل هذا في حين أنه لا يزال أسهل في التعلم وأسرع وأخف من Angular. :ابتسامة:

أضاف Marko أيضًا صيغة Jade / Pug اختيارية

يمكن لملفات .vue استخدام أي معالج أولي للقالب أو البرنامج النصي أو النمط (على سبيل المثال pug ، و typecript ، coffescript ، sass ، stylus ...) استخدم أفضل ما يناسب مشروعك!

تتطلب من المهندسين الخروج باستراتيجية وآليات لجلب البيانات

هذا مجرد مثال ، لكن جلب البيانات لا يحتاج إلى المبالغة في الهندسة:

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

من هناك ، يمكنك إنشاء مكون إضافي بسيط للغاية من Vue لجعل الكود أكثر إيجازًا.

لا ينبغي أن تكون Vue نفسها هي المكتبة المناسبة لهذه الوظيفة نظرًا لأنه سيكون هناك دائمًا مكتبات مخصصة أفضل (ولهذا السبب أيضًا لا نقدم مرشحات التاريخ افتراضيًا على سبيل المثال ، نظرًا لأنك ستنتهي باستخدام Mom أو مكتبة رائعة أخرى بدلاً من ذلك على أي حال) . نحن أيضًا بصدد كتابة كتاب طبخ بالمسارات والممارسات الموصى بها للعديد من الأعمال وحالات الاستخدام.

عندما تقوم بتغيير بعض التعليمات البرمجية ، فأنت بحاجة إلى إعادة الترجمة ، وأعد التشغيل ويجب أن يمر التطبيق بعملية التهيئة مرة أخرى.

الاختلاف الحقيقي الوحيد هو خطوة الإنشاء ، والتي يسهل إعدادها في الوقت الحاضر باستخدام أدوات مثل vue-cli أو poi الرسمية . عند حفظ ملف ، يكون التطبيق جاهزًا على الفور تقريبًا للتحديث (أوقات الإنشاء جيدة جدًا للمشاريع الكبيرة أيضًا ، ومن تجربة تطوير تطبيق PHP كبير باستخدام إطار عمل مثل Symfony يكون أكثر إيلامًا). أيضًا ، تعد ميزة Hot Module Remplacement ميزة إضافية كبيرة غير موجودة في عالم PHP (على حد علمي) وتسمح بتوفر كود جديد للاختبار في المتصفح في وقت قريب تقريبًا حتى في المشاريع الكبيرة (ما لم يكن لديك عمليات مكلفة مثل تجميع Sass - ولكن ستواجه نفس المشكلة عند استخدام PHP). بالمناسبة ، يدعم Vue webpack HMR جيدًا .

سيكون عليك التعامل مع التعقيد الإضافي.

IMHO ، يبدو أن بعض أطر PHP الشائعة جدًا أكثر تعقيدًا وأصعب في التعلم من بعض مكتبات / أطر الواجهة الأمامية مثل Vue. (والعكس صحيح أيضًا).

استنادًا إلى خبرتي التي تزيد عن عامين في إنشاء محرر قائم على الكتل مشابه لـ Gutenberg ، أعتقد أن هناك العديد من مخاوف التسنين التي يجب معالجتها عند اختيار إطار العمل الصحيح ، على سبيل المثال

• كيف تتكامل VueJS / Marko / Angular مع السحب والإفلات؟ كيف يعمل السحب والإسقاط في جوتنبرج؟ عند السحب ، هل تقوم باستنساخ عنصر شبح أم باستخدام العنصر الموجود؟ عند السقوط ، أين يمكنك إدراج عناصر نائبة لإسقاط كتلة؟

• كيف سيعمل VueJS / Marko / Angular (وعناصره الافتراضية DOM) مع Content Editables و DOM Range & Selection API؟ قد يكون من الصعب للغاية تحديد التناقضات عبر المستعرضات مع هذا النطاق والتحديد هنا.

• إلى أي مدى سيتم نسخ / قص / لصق العمل في محرر جوتنبرج؟ هل يمكنني تحديد نص بين عدة كتل وإجراء قص / نسخ / لصق؟ هل المحتوى القابل للتحرير موجود في كل كتل فردية أم أنه موجود بالكامل في محتوى رئيسي قابل للتعديل؟

• إذا كانت هناك كتل Gutenberg تحتوي على عناصر مضمنة لإطار iframe ، مثل تضمين مشغل youtube أو موجز Twitter في منشور مدونة ، فإن نقل هذه الكتلة من موضع DOM إلى موضع آخر قد يتسبب في إعادة تحميل إطار iframe نفسه. تتضمن التحذيرات الأخرى عدم القدرة على إعادة نشر الأحداث من iframe إلى المحرر (تخيل إذا كنت تسحب عنصر كتلة عبر المحرر وكان المؤشر الآن يحوم فوق iframe عبر المواقع ويتوقف كل شيء عن العمل).

جميع أطر العمل رائعة في العمل مع Virtual DOM ، ولكن الكثير من استخدام WYSIWYG يعيش خارج Virtual DOM. أعتقد أن المجالات التي يجب التركيز عليها عند تقييم إطار العمل المناسب لـ Gutenberg هي مدى جودة التعامل مع إطار العمل مع معالجة أحداث DOM ، ومتطلبات حافة النزيف التي لا يمكن إنشاؤها باستخدام إطار العمل ، ومدى سهولة بنائه خارج إطار العمل وأعد توصيله.

رأي

يعد Wordpress سهلًا بما يكفي للمطورين الجدد للتعلم كما أنه يتمتع بالكثير من القوة إذا نظرت بشكل أعمق قليلاً ، يمكن قول الشيء نفسه بالنسبة لـ Vue.
سأكون سعيدًا إذا استخدم WP هذا الإطار!

تصويتي VUE!

فيما يتعلق ببناء مكونات ويب مخصصة ، والتي أعتقد أنها مهمة جدًا للمضي قدمًا ، يوفر هذا الموقع درجة لكل إطار عمل مدرج مع معلمات الاختبار والنتائج. إنها مفيدة ، لذا ستشجع الجميع على إعطائها مرة أخرى:

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

تصويتي لـ VueJS. إطار عمل رائع ، أعتقد أن Laravel أثبت ذلك.

WP + Sage 9 (roots.io) + VueJS => مكدس مثالي

قد تكون هناك مشكلة في Preact أيضًا.

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

قد يجعلك استخدام Preact أسوأ من استخدام رد الفعل. سيسمح لـ Facebook بمنعك من استخدام رد الفعل أو الفعل المسبق حتى لو لم تبدأ الدعوى. يبدو أن هذا المحامي يعتقد أن Preact لن يكون قادرًا على تعطيل حقوق الطبع والنشر الخاصة به في المحكمة وسيعتبر انتهاكًا عند رد الفعل.

قل لي إذا كنت مخطئا. لا أعرف الكثير عن القانون لكنني أردت أن أكون مفيدًا.

قرأت هذا وهو مشابه للنصيحة القانونية التي حصلنا عليها بعد أن قررنا ذلك
التخلي عن React في مشاريعنا. ليس الأمر أن الخطر كبير. بل نحن
أراد تقليل المخاطر التي يتعرض لها عملاء المصب. هذا المحامي يضيف فقط أ
الرأي المتوافق. نحن نستخدم Polymer و Vue بدلاً من ذلك ، كلاهما يعمل بشكل رائع
لحالات استخدام محددة.

في 20 سبتمبر 2017 الساعة 11:04 مساءً ، كتب "Coding Friend" [email protected] :

قد تكون هناك مشكلة في Preact أيضًا.

https://blog.cloudboost.io/3-points-to-consider-before-
الهجرة-بعيدا-عن-رد-بسبب-فيسبوك-بسد-
براءة الاختراع-رخصة- b4a32562d268

قد يجعلك استخدام Preact أسوأ من استخدام رد الفعل. سيكون الفيسبوك
يُسمح بمنعك من استخدام رد الفعل أو الفعل المسبق حتى لو لم تبدأ
الدعوى. يبدو أن هذا المحامي يعتقد أن Preact لن يكون قادرًا على الصمود
إنها حقوق طبع ونشر في المحكمة وسيعتبر انتهاكًا على رد الفعل.

قل لي إذا كنت مخطئا. لا أعرف الكثير عن القانون لكنني أردت أن أكون مفيدًا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/WordPress/gutenberg/issues/2733#issuecomment-331045326 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AH2_iHc8Rg54IDHqe8GIyVTdSbcJbZ9Iks5skeBngaJpZM4PYie9
.

أقسمت لنفسي أنني لن أتطرق إلى WP مرة أخرى بعد رؤية الشفرة الرهيبة ، ولكن إذا استخدمت VueJS ، فقد أعيد النظر في الأمر باستخدام القليل من الفاليوم.

إخلاء المسئولية: أنا لست محاميًا. فيما يلي بدقة رأيي.

@ codingfriend1 أن هذه المقالة لها مزايا عملية قليلة.

هناك ثلاثة افتراضات:

1. يمتلك Facebook براءات اختراع واسعة بما يكفي لتغطية ما قبل الاستخدام.
2. إذا قامت شركة تستخدم preact ، على سبيل المثال ABC ، ​​بمقاضاة FB لانتهاك براءات الاختراع ، فستستخدم FB براءات الاختراع لمقاضاة ABC.
3. براءة اختراع Facebook لها مزايا.

دعونا نلقي نظرة فاحصة على جميع الافتراضات:

1. يمتلك Facebook براءات اختراع واسعة بما يكفي لتغطية ما قبل الاستخدام.

لا يوجد دليل على هذا حتى الآن. ضع في اعتبارك أن جميع براءات الاختراع عامة. كود المصدر preact هو معرفة عامة.
علاوة على ذلك ، ادعى جيسون ميلر (مؤلف سابق) أن "لا شيء من Preact يمكن براءة اختراعه - إنه واضح للغاية."

لذلك أود أن أقول إن هذا الافتراض من غير المرجح أن يكون صحيحًا. فمن الممكن، ولكن من غير المحتمل.

1. إذا قامت شركة تستخدم preact ، على سبيل المثال ABC ، ​​بمقاضاة FB لانتهاك براءات الاختراع ، فستستخدم FB براءات الاختراع لمقاضاة ABC.

سيؤدي هذا إلى تدمير سمعة Facebook. بينما أتوقع أن يحارب FB الأسنان والأظافر ، لكن استخدام براءة اختراع رد الفعل بهذه الطريقة سيصنف FB على أنه "قزم براءات الاختراع".

وفي الوقت نفسه ، لدى FB موارد كافية للقتال باستخدام الوسائل القانونية. لذلك أعتقد أن هذا الافتراض غير مرجح أيضًا.

1. براءة اختراع Facebook لها مزايا.

نعم ، هذا افتراض وليس حقيقة.

كما يحدث ، "الحصول على براءة اختراع" و "الحصول على براءة اختراع صالحة" هما شيئان مختلفان.
قرأت هذا المقال الرائع حيث قضت المحكمة ببطلان براءات الاختراع.

هناك دائمًا احتمال أن تكون براءة اختراع FB واسعة جدًا بحيث لا تتمتع بميزة.
الآن قد يظن المرء أنه إذا كان لدى facebook براءة اختراع ، فسيكون له بعض المزايا. ومع ذلك ، من الناحية المنطقية ، إذا كان يغطي ما قبل الفعل ، فهو واسع جدًا وبالتالي لا يستحق. إذن هذا الافتراض يتعارض بشكل مباشر مع الافتراض 1.

بالنظر إلى أن Facebook يستخدم براءات الاختراع للدفاع عن نفسه ، فمن المرجح أن تكون براءة اختراع Facebook واسعة النطاق ولا تستحقها ، بدلاً من أن تكون قابلة للتنفيذ.

استنتاج:

ضع في اعتبارك أن جميع الافتراضات الثلاثة لم يتم اختبارها. إذا تبين أنها كلها صحيحة ، - وهذا ممكن تقنيًا - إذن ، "نعم ، استخدام preact أمر خطير."

ومع ذلك ، من الناحية العملية ، فإن فرص كون الافتراضات الثلاثة صحيحة منخفضة للغاية ، خاصة الافتراضين 1 و 3 معًا.

لذا حتى وما لم تحكم المحكمة خلاف ذلك ، أود أن أقول إن استخدام preact (ومكتبات vdom الأخرى) آمن تمامًا.

فيما يتعلق بالنقطة 1 ، يمتلك Facebook براءة اختراع تسمى تفويض الحدث الفعال في نصوص المتصفح . هذه أساسًا دالة jQuery live() (أصبحت لاحقًا جزءًا من on() في jQuery API)!

ومع ذلك ، بغض النظر عن صحة الافتراضات ، فإن سبب ابتعاد WordPress عن React ليس أن WordPress لديه مخاوف بشأن Facebook. وأنا أقتبس من منشور الإعلان المرتبط بالمسألة أعلاه ( حدد لي):

أعتقد أن شرط Facebook هو في الواقع أكثر وضوحًا من العديد من الأساليب وإقناع العالم بأن شرط براءة Facebook لا بأس به ليس من اختصاصنا.

بناءً على ذلك ، فإن الإدراك والارتباك والأسئلة التي تجلبها براءة الاختراع هي التي دفعت WordPress بعيدًا. أعتقد أن نفس المخاوف تنطبق على Preact أيضًا ، كما هو موضح في تعليقي السابق .

فيما يتعلق بالنقطة 1 ، يمتلك Facebook براءة اختراع تسمى تفويض الحدث الفعال في نصوص المتصفح. هذه في الأساس وظيفة jQuery's live () (أصبحت لاحقًا جزءًا من on () في jQuery API)!

فهل يعني ذلك أنهم اخترعوا فكرة الوفد على الإطلاق ؟! أرى بعض الاستشهادات هناك والتي تعود إلى عام 1995 ، ماذا يعني ذلك؟

ChrisCinelli فيما يتعلق بما

أعتقد أن هذه مجرد مسألة مقياس. عندما يحتوي مشروع ما على 5k أو حتى 10k نجمة Github ، فإن حدثًا واحدًا مثل رابط في الصفحة العليا من Hackernews يمكن أن يجلب 1k نجمة في اليوم ، وهو في حالة Marko يمثل 20٪ من العدد الأخير.

على مقياس 65 ألف نجم الذي تمتلكه Vue ليس مرئيًا. يمكنك حتى أن ترى أنه بسبب كيفية عمل نص تاريخ النجوم ، فإنه يتوقف في مرحلة ما عن إظهار التقلبات على الإطلاق وهو مجرد خط مستقيم حتى النهاية.

مثل هذا الموقف ليس فريدًا بالنسبة لماركو نفسه ، فقد حدث في Inferno أو مؤخرًا لـ MoonJS وهو إطار مصغر مستوحى من Vue. يمكنك حتى أن تقول أن Preact يبدو في نقطة مماثلة بسبب عدد النجوم التي حصلت عليها مؤخرًا بسبب الدراما الكاملة لبراءات اختراع React.

يمكنك ملاحظة ما أتحدث عنه في الرسم البياني التالي من نفس مصدرك:

سيحدد الوقت ما إذا كان هؤلاء الأشخاص سيحاولون بالفعل تجربة الإطار قيد التطوير ، وسيستخدمونه في الإنتاج ويستمرون في استخدامه لاحقًا. أتمنى لماركو التوفيق ، مثل أي مكتبة أخرى مفتوحة المصدر.

بالنسبة إلى Vue ، نعم ، إنه نمو مستقر بدون تقلبات كبيرة. مع السرعة الحالية ، يجب أن تتصدر React قبل عيد الميلاد. على الأقل على جيثب. :)

ماذا عنaurelia؟
الموقع: aurelia.io
EisenbergEffect خلق هذا.

بالنسبة لي ، إنه إطار عمل رائع!

1. اصطلاحات بسيطة (يمكن تخصيصها)
2. HTML عادي
3. الفانيليا شبيبة
4. لا تدخل إطار!

يمكنك أيضًا إضافة اختيارك للمكتبة (jQuery ، Vue.js ، Preact ، Ember ، HyperHTML ، إلخ ...) التي تريد استخدامها وتعليم Aurelia كيفية استخدامها!

إنه أمر بسيط للغاية ومبني على المعايير ، فلن تحتاج حتى إلى دعم المجتمع ، وإذا كنت تعتقد حقًا أن دعم المجتمع مهم ، فقد قاموا بتغطيتك أيضًا (بأكثر من 10 آلاف نجمة).

موارد لـ aurelia :

1. تقديم Aurelia
2. مدونة أوريليا
3. أوريليا دوكس

يبدو أنه تم إعادة ترخيص React تحت MIT: https://code.facebook.com/posts/300798627056246

أفترض أنه يجب عكس القرار الآن.

هولي مولي! React عاد للعمل. فعل WordPress ذلك؟ غير متأكد! إنها الثالثة صباحًا وأنا متحمس جدًا لهذا الأمر! ماذا عنك!

إعادة ترخيص التفاعل ، والدافع ، والتدفق ، والثابت. js

في الأسبوع المقبل ، سنقوم بإعادة ترخيص مشاريعنا مفتوحة المصدر React و Jest و Flow و Immutable.js بموجب ترخيص MIT. نحن بصدد إعادة ترخيص هذه المشاريع لأن React هي أساس نظام بيئي واسع من البرامج مفتوحة المصدر للويب ، ولا نريد إعاقة التقدم لأسباب غير تقنية.

يأتي هذا القرار بعد عدة أسابيع من خيبة الأمل وعدم اليقين لمجتمعنا. على الرغم من أننا ما زلنا نعتقد أن رخصة براءات الاختراع BSD + الخاصة بنا توفر بعض الفوائد لمستخدمي مشاريعنا ، فإننا نقر بأننا فشلنا في إقناع هذا المجتمع بشكل حاسم.

في أعقاب عدم اليقين بشأن ترخيصنا ، نعلم أن العديد من الفرق مرت بعملية اختيار مكتبة بديلة لـ React. نحن آسفون على هذا الاضطراب. لا نتوقع عودة هذه الفرق من خلال إجراء هذا التغيير ، لكننا نريد ترك الباب مفتوحًا. التعاون الودي والمنافسة في هذا الفضاء يدفعنا جميعًا إلى الأمام ، ونريد المشاركة بشكل كامل.

يثير هذا التحول بطبيعة الحال أسئلة حول بقية مشاريع Facebook مفتوحة المصدر. ستحتفظ العديد من مشاريعنا الشهيرة بترخيص BSD + Patents في الوقت الحالي. نقوم بتقييم تراخيص تلك المشاريع أيضًا ، لكن كل مشروع مختلف وستعتمد خيارات الترخيص البديلة على مجموعة متنوعة من العوامل.

سنقوم بتضمين تحديثات الترخيص مع إصدار React 16 الأسبوع المقبل. لقد عملنا على React 16 منذ أكثر من عام ، وأعدنا كتابة مكوناته الداخلية بالكامل من أجل إطلاق العنان لميزات قوية ستفيد الجميع في بناء واجهات مستخدم على نطاق واسع. سنشارك المزيد قريبًا حول كيفية إعادة كتابة React ، ونأمل أن يلهم عملنا المطورين في كل مكان ، سواء استخدموا React أم لا. نتطلع إلى وضع مناقشة الترخيص وراءنا والعودة إلى أكثر ما يهمنا: شحن المنتجات الرائعة.

في رأيي ، مع ترخيص MIT ومع وجود أكثر مجتمعات JS مفتوحة المصدر نشاطًا وأكبر وراءها - فإن React هو الخيار المحدد الذي يجب الالتزام به.

عاد تصويتي مع React الآن . - الإيمان في الإنسانية استعادة.

التصويت باستخدام with بدلاً من التعليقات المماثلة.

أود أن أعبر عن شكري الهائل لـ Wordpress لمشاركتي في ما أدى إلى هذا التغيير في React lincencing.

ما زلت أعتقد أن Vue سيكون الحل الأفضل. لا تزال العديد من نقاط القوة من Vue سارية ، لكنني أريد أن أشير إلى أن الود للمبتدئين وعدم الاضطرار إلى استخدام خطوة بناء هي ، في رأيي ، ميزات قاتلة في بيئة Wordpress.

للكتلة
بالتأكيد
من أجل vueJS

اخترت أيضًا Angular2.0 + (وليس AngularJS) ، التي تضم أكبر مجتمع ، وفريق مطور قوي ، ونظام بيئي مستقر وكامل.

CrazyBBer أين يمكنني العثور على بعض البيانات حول أكبر مجتمع هو Angular 2/4؟ سوف يساعدني مع وظيفة بلوق.

على أي حال ، انتهى الأمر يا رفاق ، إن React هنا لتبقى مع WordPress وحتى بصفتي متحمسًا لـ Vue ، أجد أن أفضل طريقة يمكن أن ينقلب بها الموقف ، بالنظر إلى مقدار الشفرة المكتوبة بالفعل باستخدام React.

ahmadawaisgustojs أثار الأشخاص في Reddit مخاوف من أن معهد ماساتشوستس للتكنولوجيا (MIT) يغطي حقوق الطبع والنشر فقط ، لذلك لن يحصل المطورون على منحة براءة اختراع عند استخدام React والتي أفترض أنها لا تزال تمثل مشكلة.

كما أن هذا البيان يزعجني حقًا:

نعترف بأننا فشلنا في إقناع هذا المجتمع بشكل حاسم.

القول بفاعلية "لم نكن مخطئين - أنتم مطورو البرامج لم تفهمونا".

ahmadawais : ما زلت أعتقد أن استخدام Vue سيكون خيارًا أفضل لأنك رأيت مثالًا رائعًا على مدى تقلب ترخيص React ، أولاً كان لديهم BSD + Patents license الآن ، التحول إلى MIT. من يدري في المستقبل القريب قد يعودون مرة أخرى إلى ترخيص / براءة اختراع مملوكة لـ FB وبعد ذلك سيتم تعليق الجميع حتى يجف. لقد كان Vue معهد ماساتشوستس للتكنولوجيا منذ البداية وهو مدفوع بالمجتمع أكثر من شركة كبيرة مدفوعة.

بالإضافة إلى ما قاله @ atanas-angelov-dev.

لا جدوى من التبديل الآن بعد ذلك.
أعتقد أن Vue تقدم منظورًا أفضل ولكن هذا يعني إعادة كتابة كل شيء

آه! هيا أيها الناس ، فقط أعط الفرصة لأوريليا!
تم إنشاؤه بواسطة أحد المطورين الرئيسيين من فريق Angularjs.
يمكنك الانتقال من تبني صغير إلى إطار كامل مثل Vue.js

حتى فريق بوابة azure قال إنه لو كانوا
و من يعلم؟! ربما كانوا يهاجرون إلى أوريليا شيئًا فشيئًا الآن.

ابدأ قليلاً ، أعلم أنك ستعجبك!

نيرمال 4 جي ،
أطروحتك تبدو مقلقة لدرجة أنها سخيفة.
في الواقع ، أعتقد أن الإطار بأكمله به نفس العيوب مثل صفحة 404 التي ترتبط بها مباشرةً في مشاركتك.
http://aurelia.io/get-started.html

@ bovas85 ليس salesly، وأنا لست حتى جزءا من هذا الفريق. إنهم لا يعرفون حتى أنني أستخدم إطار عملهم.

@ cr101 / سم مكعب

لا تحكم على الكتاب من غلافه

لقد استخدمت العديد من الأطر الشائعة حتى قبل أن أعرف عن Aurelia. إذا اضطررت إلى التكديس من خلال موازنة كل المعايير الموجودة هناك ، بالنسبة لطلبي (صدقوني إنه تطبيق كبير) ، فإن Aurelia تتصدر القائمة وتتبعها Vue.

أعتقد أن الإطار بأكمله به نفس العيوب مثل صفحة 404 التي ترتبط بها مباشرةً في منشورك.

كل رابط قمت بنشره لا يذهب إلى صفحة 404. إنه خطأ جيثب في إعادة توجيه http إلى موقع https. تم إصلاحه الآن. انظر ، حشرة. أخبرني عن أي إطار لا يحتوي على أخطاء ، أتحداك.

إنه فقط مع الأطر الأخرى لديك الكثير من التجريدات الزائدة عن الحاجة (لكنها مفيدة). لا يتبنى مجتمع W3C أبدًا تصميم إطار عام في واجهة برمجة التطبيقات الخاصة بهم ، لذا فهناك الكثير من الأفكار التجريدية.

يركز كل إطار عمل على التوافق مع الإصدارات السابقة ويفقد التوافق مع الإصدارات السابقة ولكن Aurelia لا تفعل ذلك ، طالما أنك تلتزم بمواصفات HTML و W3C و ECMAScript لـ HTML ، فإن كودك JS يعمل بشكل جيد.

_إذا لم يكن هناك Aurelia ، فلن أمانع في التمسك بـ Vue. إنه ثاني أفضل شيء.

_ إنها مجرد مسألة قبول معيار بدلاً من إنشاء طريقة جديدة لإعادة اختراعه ._

@ Nirmal4G يرجى تقديم أدلة على ادعاءاتك أو تجنب الأسماء. بالكاد أعتقد ، خاصة عندما يتعلق الأمر بـ LOC ، كان Vue أقل من hyperHTML. كل ما كتبته بلغة hyperHTML مقارنةً بـ vue كان أقل من LOC ، حيث جمع التخطيط والمنطق معًا . بقدر ما لا أؤمن حتى بـ LOC كمقياس ذي صلة بأي شيء ، فإن قراءة FUD غير المثبتة لا تبدو عادلة بالنسبة لي.

WebReflection امسك خيولك ، لم أقل إنك أسوأ من Vue. آسف إذا كنت قد أساءت إليك.

يستخدم تطبيقي كل ما يمكنك رميها فيه. لقد جربت نموذجًا أوليًا مع العديد من الأطر ، وكان أحد المعايير التي أمتلكها هو LOC ولكن من وجهة نظر بصرية ، ليس للسبب الذي تعتقد أنه يمكن تحسين أداء أي إطار عمل ، ولكن خيارات التصميم هي التي تأتي مع الاسم.

لقد قمت بتقييم HyperHTML ، كان الأداء مثيرًا للإعجاب ، ولم يكن هناك polyfills رائعًا ، ولكن للأسف لم يتم إجراء القطع بالنسبة لمتطلباتي.

كل إطار لديه شيء أفضل ، أمنيتي هي أنه إذا كان بإمكان أي شخص أن يجمع بين أفضل الأطر الموجودة هناك بتصميم أفضل سيكون إلهيًا ، لكن هذا لن يحدث. لذلك ، يجب أن أجد هذا التوازن حيث يمكن لإطار العمل تحسين نفسه في المستقبل وحيث لا يمكنه ذلك.

من الجيد حقًا أن نسمع أن React ستكون الآن MIT.
يجعلني متحمسًا جدًا لهذا المشروع وأنا أتطلع إلى البدء في استخدام WordPress مرة أخرى بعد وقت طويل ، بمجرد دعم React و WP API بالكامل. :)

دعنا ننتظر ونرى ما سيكون ترخيص React الفعلي. معهد ماساتشوستس للتكنولوجيا أو معهد ماساتشوستس للتكنولوجيا + براءات الاختراع ..؟ ؛)

أنا شخصياً أحب React لكني أجد Vue أكثر إنتاجية. سأكون سعيدًا بأي منهما ، لكن ...

... مع الأخذ في الاعتبار الدعم القوي لـ Vue من قبل المجتمع ، أقترح أخذ ذلك في الاعتبار ، بالإضافة إلى الترخيص.

يبدو أن Vue هو الخيار الأنسب لـ WordPress.

قام Facebook بإزالة 4 عناصر من مجموعة فخ التقاضي. هذه كلها الآن مرخصة من معهد ماساتشوستس للتكنولوجيا:

• تتفاعل
• دعابة
• تدفق
• غير قابل للتغيير

وفي الوقت نفسه ، لا يزال ترخيص Facebook من الفئة X ساريًا على:

• رد الفعل الأصلي
• GraphQL
• غزل
• تناوب
• أتوم IDE
• ومن المحتمل أن يكون أي شيء آخر من صنعهم ومصدر "مفتوح"

ما زلت أقول اذهب مع Vue. إنه يستحق ذلك على المدى الطويل. لم تكن React منطقية بالنسبة لي بالنسبة إلى Wordpress على أي حال. إنه جزء لا يتجزأ من مجتمع PHP ، ويبدو دائمًا أن Vue هو الخيار الأكثر حساسية (بالإضافة إلى أنه ليس من المؤلم استخدامه مثل React).

وفي الوقت نفسه ، لا يزال ترخيص Facebook من الفئة X ساريًا على:

رد الفعل الأصلي
GraphQL
غزل
تناوب
أتوم IDE
ومن المحتمل أن يكون أي شيء آخر من صنعهم ومصدر "مفتوح"

TheJaredWilcurt آسف ولكن ربما ترغب في إزالة الغزل من تلك القائمة .. لا يحتوي الغزل على ترخيص "Facebook Category X" -> https://github.com/yarnpkg/yarn

@ atanas-angelov-dev

أثار الأشخاص في Reddit مخاوف من أن معهد ماساتشوستس للتكنولوجيا يغطي حقوق الطبع والنشر فقط ، لذلك لن يحصل المطورون على منحة براءة اختراع عند استخدام React والتي أفترض أنها لا تزال تمثل مشكلة.

معهد ماساتشوستس للتكنولوجيا هو رخصة عظيمة. jQuery حاصل على ترخيص MIT أيضًا. وآمل أن نعلم أن.

vinayakkulkarni ما زلت أعتقد أن استخدام Vue سيكون خيارًا أفضل لأنك رأيت مثالًا مثاليًا على مدى تقلب ترخيص React ، أولاً كان لديهم رخصة BSD + براءات الاختراع الآن ، والانتقال إلى MIT. من يدري في المستقبل القريب قد يعودون مرة أخرى إلى ترخيص / براءة اختراع مملوكة لـ FB وبعد ذلك سيتم تعليق الجميع حتى يجف. لقد كان Vue معهد ماساتشوستس للتكنولوجيا منذ البداية وهو مدفوع بالمجتمع أكثر من شركة كبيرة مدفوعة.

هذه ليست طريقة عمله. قرأت تعليق صموئيل على الفيسبوك على سؤال مشابه. بمجرد أن تقوم بترخيص MIT ، يمكنك إما تغييره لتغيير الترخيص أو لا يمكنك ذلك. أنا لست محاميا رغم ذلك.

أيضًا ، شخصيًا أعتقد أن Facebook قد فعل ذلك كبادرة حسن نية وليس لخداع الناس. هذا يعني شيئا بالنسبة لي.

أيضًا ، شخصيًا أعتقد أن Facebook قد فعل ذلك كبادرة حسن نية وليس لخداع الناس. هذا يعني شيئا بالنسبة لي.

هذا ليس بيانًا منطقيًا للغاية. أنت تكافئ مجموعة واحدة لأنها توقفت عن فعل شيء سلبي ، بدلاً من مكافأة المجموعة التي لم تفعل الشيء السلبي على الإطلاق. أيضًا ، كما هو مذكور أعلاه ، لا يزالون يستخدمون ترخيص الفئة X في مشاريع أخرى مماثلة ، وهي ليست علامة على حسن النية بالنسبة لي.

تتمتع Vue بمنحنى التعلم والاعتماد اللطيف.
وكانت هذه هي الفكرة الأساسية الأساسية لـ WordPress منذ البداية.

أعرف ahmadawais - معهد ماساتشوستس للتكنولوجيا (MIT) جيد بقدر ما تحصل عليه التراخيص ولكن ، وهذا شيء كبير "لكن" ، يبدو أن Facebook لديه براءات اختراع على React وبينما يسمح لك MIT باستخدام الرمز لأي غرض ، قد ينتهي بك الأمر إلى التعدي على Facebook براءات الاختراع (خذ كل هذا مع صخرة ملح - IANAL)

ومن أجل البقاء في الموضوع ، يجب أن أقول إنني أرى الكثير مما جعل WordPress رائعًا في Vue أيضًا - في رأيي المتواضع ، لا توجد مكتبة أخرى مناسبة سهلة التعلم والاستخدام مثل Vue.

يبدو أن Facebook لديه براءات اختراع على React

ما هو الجزء الذي تعتقد أنه مسجل ببراءة اختراع في React؟ (لا يوجد براءة اختراع في React ، حاول إجراء بحث أولاً) إظهار الروابط ، ليس فقط "ظاهريًا" .. ، هذا هو نوع التعليقات التي لا تساعد على الإطلاق. إذا كنت تريد أن توصي مكتبتك المفضلة ، فافعل ذلك بالطريقة الصحيحة ، مع إظهار مزاياها ، وليس مجرد نشر FUD.

لماذا الانتقال الأصلي إلى BSD + براءات الاختراع إذا لم يكن لدى React براءات اختراع وراءه؟ لم يقل Facebook ما هم عليه ، أو ما هم ليسوا كذلك.

لماذا تسكع مع الترخيص لمدة 2 سنة وفقط إجراء تغيير لجزء من محافظهم، وكان على الدوام قالوا انهم لن تغييره، وقال "مجرد التعامل معها، ونحن لا نهتم إذا كنت تستخدم ذلك أم لا".

لماذا تستبعد React Native و GraphQL وما إلى ذلك من الترخيص "الجديد"؟ ما هي النسخة المستقبلية من React التي ستتحول إليها؟ لا توجد ضمانات عندما يكون لديك ترخيص من مستويين من Facebook ، اعتمادًا على من يشتكي من ذلك ...

ماذا لو تم إدخال جزء من كود React Native في React. ما هو موقفك إذا كان تنفيذ GraphQL يشق طريقه إلى قاعدة بيانات ..؟

يثير هذا الإجراء من قِبل Facebook أسئلة أكثر مما يجيب ، ولا يزال يعني أن كل استخدام فردي لـ React يمثل خطرًا محتملاً على مشاريع مفتوحة المصدر حقيقية.

ما عليك سوى اعتماد المكتبة الخالية من الأمتعة التي تم إنشاؤها بالفعل في عالم PHP - Vue.

bjrmatos https://www.google.com/patents/US20170221242 أعتقد!

+1 آخر لـ Vue. لا يزال Facebook يستخدم ترخيصين خلال مشاريعهم. هذا ليس جيدا.

PericlesSouza من الواضح أنك تتجاهل الجهد الكبير الذي تقوم به شركة مثل facebook لتحسين الأمور ودفع الويب إلى الأمام ، ويمكن الإجابة على جميع مهامك إذا قرأت للتو المنشور حول التغيير إلى MIT. لا أعرف حقًا لماذا لا تزال تثير هذا القلق غير المنطقي بشأن ترخيص معهد ماساتشوستس للتكنولوجيا ، فمع التغيير ، أصبحت React في نفس الوضع مثل أي مشروع "True Open Source" (لا أعرف ما تسميه مشروع True Open Source بالمناسبة).

Raymonf حسنًا ، في الأساس أي إطار عمل حديث هناك ينتهك براءة الاختراع هذه بالفعل (بما في ذلك Vue) ، لذا فإن أي شخص في نفس الموقف بغض النظر عما إذا كنت تستخدم React أو Vue أو إطار عمل آخر ينفذ المفهوم الموضح في الرابط (راجع للشبكة بشكل أساسي أي ويب هناك مشروع ينتهك بالفعل براءات اختراع أو ثلاث براءات اختراع مملوكة لشركات أخرى ، وسوف تفاجأ بمعرفة نوع الأشياء التي تم تسجيل براءات الاختراع من قبل الشركات في الوقت الحالي). إذا كنت قلقًا حقًا بشأن ذلك ، فهذا يعني أنه لا يمكنك استخدام أي إطار عمل يقوم بتحديث واجهة المستخدم بهذه الطريقة .. لذلك في هذا السياق القانوني لا يوجد بديل أفضل أو أسوأ.

لا أريد الانخراط في هذا النوع من المحادثات مرة أخرى لأنه سيكون من المستحيل الوصول إلى اتفاق لذلك سأتوقف عن تعليقاتي. مجتمع React سعيد بالتغيير إلى MIT (حتى أكبر منتقدي الترخيص الأصلي)

حظًا سعيدًا لفريق WordPress في القرار ، تم حل المشكلة الرئيسية حول ترخيص React BSD + Patents ، والآن أصبح اتخاذ القرار مهمتهم.

لذلك قام Facebook مؤخرًا بتغيير ترخيص React الخاص به. هل هذا يعني أن WordPress سيستمر في استخدام React أو سيظل يغير إطار عمل الواجهة الأمامية الافتراضي؟

bjrmatos هذا ليس صحيحًا على الإطلاق

في الأساس أي إطار حديث هناك ينتهك براءة الاختراع بالفعل

على سبيل المثال ، لا يستخدم hyperHTML DOM الظاهري ، بل يستخدم مباشرة DOM API (غير قادر على براءة اختراع) من خلال استدعاءات رد الاتصال العادية (غير قادرة على براءة الاختراع) وخوارزمية الفرق الوحيدة لتحويل c hildNodes: after في قوائم العقد على أساس مسافة Levenshtein (غير الحاصلة على براءة اختراع) وأقل قدر من عمليات لصق (غير قادر على براءة اختراع ، لقد كتبت ذلك وهو ISC ).

وبينما أعتقد في هذه المرحلة أن هذا الخيط قد عفا عليه الزمن ولا طائل من ورائه ، لا أفهم الحاجة إلى الاستمرار في نشر FUD. إذا قمت باختيار ما وأعجبك ، فلا يوجد سبب لإخبار الآخرين بأنهم يفعلون شيئًا خاطئًا أو أنهم في نفس المشاكل التي تواجهها. أتمنى أن نتفق على هذا.

noncotient هذا سؤال مليون دولار ، أليس كذلك؟ 💯

لقد ألغيت اشتراكي هنا لأن المناقشة أصبحت بلا جدوى بعض الشيء.
أعتقد أنه تم المضي قدمًا في الكثير من النقاط الجيدة وكانت تجربة تعليمية لكل من قرأ هذا العدد بعناية.

أوافق ، هذا الآن لا طائل منه. أقترح إغلاق هذا الموضوع (أو ربما المساهمون فقط). كانت هناك تعليقات كافية حول هذه المسألة ، وهي الآن تصل إلى النقطة التي ستؤدي فيها فقط إلى حجة غير بناءة.

هل سيتم إغلاق هذه القضية؟
يبدو أن @ WordPress غير مهتم

بالنسبة لي ، أنا شخصياً أحب vuejs. لكن يبدو أنه لا يهم الآن. 😅

أنا شخصياً أفضل Vue بغض النظر.

بالنسبة لي ، وأعتقد أن العديد من الأشخاص الآخرين ، لم يكن الأمر يتعلق مطلقًا بالترخيص. كان هذا مجرد ذريعة للابتعاد عن React.

ماركو قوي وسهل بجنون. نحن الآن بصدد الانتهاء من إعادة كتابة كاملة لمتجر ويب ديناميكي يحتوي على 50000 منتج وهو متوهج وعميق للغاية في الميزات. اذهب في هذا الطريق ولا تنظر للخلف.

Marko جيد ولكن Prarko أصغر Plarko غدًا ، مع إضافة الألياف ، مما يجعل _ كل شيء _ زائدة عن الحاجة.

آسف ، ولكن هذه هي الطريقة التي يتجه بها بقية هذا الموضوع.

دعنا ننتظر ونرى ما هو الترخيص الفعلي عند إصداره ، وما هي الآثار المترتبة على ترخيص Facebook من مستويين ، ونرى القرار الذي يقرره فريق WordPress بمجرد التحقيق في المشكلة بدقة.

أعني ، لقد طلبت في الأصل إدخال مدخلات على المحركات التي يحبها المجتمع. ويبدو أن هذا هو ما ينشره الأشخاص ، إلا أن بعض الأشخاص يقفزون في كل مكان لإرسال تعليقات تتماشى مع ما طُلب منهم. كندة غريبة.

جميع المكتبات / الأطر المذكورة هنا ممتازة ؛ بعضها أكثر ملاءمة لبعض السيناريوهات من غيرها. سيكون لكل منها دعاة ، وسيتخطى كل منهم الآخرين من حيث الأداء / الميزات ، اعتمادًا على دورات التطوير الخاصة بهم.

ربما أبدأ بسؤال بسيط ، كما أفعل في معظم المشاريع:

1. هل نحتاج إلى إطار عمل SPA؟

إذا كان الجواب نعم ، فقم بالتفصيل لماذا. يمنحك هذا مجموعة من المعايير لتقييم المرشحين المحتملين ؛ ربما لتقديم جانب الخادم ، وربما التوجيه ، وما إلى ذلك.

إذا لم يكن كذلك ، اطرح السؤال التالي:

1. ما نحن حقا في حاجة الى قالب المحرك؟

لدى VanillaJS أكبر مجتمع على هذا الكوكب ، ولا توجد مشكلات في الترخيص. إنها أيضًا متوافقة مع المعايير ؛) ، ومع وحدات ES6 ، قد توفر أساسًا مناسبًا للتطوير الأساسي ، مع القدرة على دعم المكونات الإضافية لاستخدام محركات _template_ مثل React و Vue و Preact و Aurelia وما إلى ذلك. كل ما سيتم إصداره في السنوات القادمة ، حسب طلب المطورين.

نشر مات مولينويج رده ...

أنا مندهش ومتحمس لرؤية الأخبار التي تفيد بأن Facebook سوف يتخلى عن بند براءة الاختراع الذي كتبته الأسبوع الماضي. لقد أعلنوا أنه مع React 16 ، سيكون الترخيص مجرد MIT عادي بدون إضافة براءات الاختراع. أحيي فيسبوك لاتخاذ هذه الخطوة ، وآمل أن تتم إعادة فحص استخدام بند براءات الاختراع في جميع مشاريعهم مفتوحة المصدر.

أثار قرارنا بالابتعاد عن React ، بناءً على موقفهم السابق ، الكثير من المناقشات الشيقة في عالم WordPress. على وجه الخصوص مع Gutenberg ، قد يكون هناك نهج يسمح للمطورين بكتابة كتل Gutenberg (Gutenblocks) في المكتبة التي يختارونها بما في ذلك Preact أو Polymer أو Vue ، والآن يمكن أن تكون React خيارًا مدعومًا رسميًا أيضًا.

أود أن أشكر كل من شارك في المناقشة حتى الآن ، فأنا أقدر ذلك حقًا. كان النقاش والنقاش القوي في التعليقات هنا وعلى Hacker News و Reddit رائعًا للشغف الذي جلبه الأشخاص وفرصة التعرف على العديد من وجهات النظر المختلفة ؛ كان من الأفضل أن Facebook كان يستمع.

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

ahmadawaism

أثار قرارنا بالابتعاد عن React ، بناءً على موقفهم السابق ، الكثير من المناقشات الشيقة في عالم WordPress. على وجه الخصوص مع Gutenberg ، قد يكون هناك نهج يسمح للمطورين بكتابة كتل Gutenberg (Gutenblocks) في المكتبة التي يختارونها بما في ذلك Preact أو Polymer أو Vue ، والآن يمكن أن تكون React خيارًا مدعومًا رسميًا أيضًا.

قد يبدو هذا الوضع وكأنه فوز للجميع. دعنا ننتظر ونرى كيف ينتهي هذا الأمر بالفعل.

فقط أغلق هذه المسألة الآن .. إنها تذهب فقط لترى مدى تقلب العالم .. حزين لرؤية الناس لا يلتزمون بكلمتهم.

[تحرير: تمت إزالته بسبب بيان مسيء]

حظًا سعيدًا لكل من عليه استخدام Gutenberg ومنحنى التعلم الثقيل لتعلم React باستخدامه.

سلام.

👋 أعتقد أننا جميعًا أجرينا الكثير من المناقشات هنا. أود أن أشكر كل من اهتم بما يكفي للتحدث والتعليق على هذه المسألة. IMHO يبدو أن جميع الخيارات التي لدينا الآن خيارات جيدة.

إذا انتهينا من استخدام واجهة برمجة تطبيقات أفضل لإطار العمل ، فسيكون بإمكان المرء استخدام أي إطار عمل JS يريده في تطبيقاته. مع ترخيص MIT ، تتمتع React بمكانة قوية لاستخدامها في جوهرها مثل أي مكتبة أخرى ذات ترخيص مفتوح المصدر جيد (متوافق للقراءة).

🎯 إذا كنت تقوم بالتجذير لإطار عمل JavaScript معين ، أو قمت ببناء واحدة (فرق أساسية) ، أقترح عليك إنشاء أمثلة فعلية لمطوري WordPress حتى يتمكن الأشخاص من البدء في اللعب بفكرة استخدام إطار عمل JavaScript المفضل لديك في التطبيقات المستندة إلى WordPress. بناء.

أنا أغلق هذه التذكرة الآن. وتأمل في المساهمة بشكل أكبر في نجاح WordPress كمنصة وكمجتمع. نتوقع نفس الشيء من الجميع هنا. أعتقد حقًا أن هذه ستكون مغامرة أفعوانية لأي شخص يعمل مع برنامج WordPress.

في وقت ما من الآن ، قد ينتهي بنا الأمر إلى تحسين البرنامج للمساعدة في تسهيل الأمر على مستخدميه (حوالي 30٪ من مواقع الإنترنت) كما كان الحال قبل عامين. أنا أقوم بتجذير WordPress هنا ، مثلكم جميعًا!

في صحتك!

ليس من الواضح من تعليق ماتس ما إذا كان قرار الابتعاد عن React قد أُلغي.

أولاً ، لم يتم نشر الترخيص الفعلي الذي سيستخدمه Facebook بعد ، لذا فإن التظاهر بانتهاء كل شيء ليس خطوة معقولة حقًا.

ثانيًا ، لا يتناول الترخيص ذو المستويين الذي يتبعه Facebook: قد تكون React هي MIT ، لكن React Native ستكون + (غير معلنة) براءات الاختراع .

إذن .. ماذا عن المكونات التي يتقاسمها كلاهما؟

ماذا عن شفرة React Native المستخدمة في React؟ هل سيتم تقاسم الألياف بين رخصتين مختلفتين؟ أو تجد كود GraphQL طريقًا إلى React؟

ماذا يحدث لـ WordPress إذا ذهب إلى مسار React ، مع نشر جميع مشاريع Facebook ذات الصلة هذه بموجب ترخيص مختلف ، ثم قرر Facebook أن بعض جوانب React تخضع فعليًا ، على سبيل المثال ، منحة React Native Patent Grant أو الألياف الضوئية منحة براءات الاختراع؟

بجدية ، فكر مليًا في هذا الأمر. لماذا المخاطرة بها عندما تكون هناك بدائل تفضل الأغلبية استخدامها ، ولا توجد بها هذه المشكلة - Vue.

لن أثق في اتفاقية ترخيص تتغير مع الريح ، بدلاً من التفكير فيها بشكل صحيح. يمكن لمحامي Facebook تغيير هذا الأمر لمجرد نزوة.

التمسك بالمصدر المفتوح الأصلي.

PericlesSouza سيكون الترخيص هو بالضبط ما يتخيله الناس هنا من وصف

تضمين التغريدة

أنت تعمل في Facebook. إذا لم تكن محاميًا مخولًا للتحدث نيابة عن Facebook ، فلا يهم ما تدعي. لا يهم حتى الرمز الذي تكتبه. آسف.

تراخيص "التخيل" لا تقف في المحكمة.

على سبيل المثال ، هل يمكنك أن توضح بشكل قاطع سبب اعتماد Facebook لمنحة براءات الاختراع ، وما هي براءات الاختراع (أو لم تكن كذلك) ، أو لماذا يقولون إنهم يغيرونها الآن ، دون قول "IANAL" (أنا لست محاميًا)؟

القطع التي يشاركها كلاهما تعيش في مشروع React ، وليس في React Native

لكن هل يمكنك قول ذلك بضمان قانوني؟ لا؟

ستتوفر React وتبعياتها المملوكة لـ FB تحت إم آي تي ​​بمجرد أن يتاح لفريقنا الوقت الكافي لتنفيذ التغييرات

ما الأجزاء التي تتم إزالتها للسماح بنشر React تحت MIT؟ ما هي التبعيات غير المملوكة لـ FB والتي من المفترض أنها لم تكن متوافقة مع MIT التي كنت تستخدمها بالفعل ..؟ هل سيضمن محامو Facebook أن كل شيء متوافق حقًا مع MIT؟ كم من الوقت ستستغرق مؤسسة Apache Software Foundation للتصديق على ذلك؟
.

يبدو أنني كنت محقًا في تسليط الضوء على أن الكود يتم مشاركته بين مشروعين من الواضح أنهما سيحصلان على ترخيص من مستويين.

أنت تحرف كلماتي. سيتم ترخيص الكود المشترك بين React و React Native بموجب MIT. سيتم ترخيص كل ما تعتقده على أنه الألياف الضوئية بموجب MIT. لن تتضمن React أو تعتمد على أي كود مرخص بموجب BSD + براءات الاختراع أو أي منحة براءات اختراع أخرى تكرهها. نحن لا نزيل أجزاء من React. إن تبعية React الوحيدة غير المملوكة لـ FB والتي أعرفها هي تخصيص كائن وهو أيضًا تحت MIT.

أنا لا أقترح عليك أن تأخذ كلامي كضمان قانوني. كلانا يعلم أن تعليقاتي هنا لا تغير ترخيص React بحد ذاتها. يمكنك اختيار أن تكون متشككًا ولا يتعين عليك تصديقني الآن ، ولكن في غضون يوم أو يومين سترى أن ما أقوله هنا صحيح.

تضمين التغريدة

أنا لا ألوي كلماتك - وأنا أحترم العمل الذي تقوم به واستعدادك للانخراط هنا.

أنا أقول ببساطة أنه ما لم وحتى نحصل على التزامات قانونية من Facebook ، من قبل المسؤولين المعتمدين من الشركة ، والتي تم التحقق منها من قبل هيئات خارجية مفتوحة المصدر ، فإننا لا نزال في نفس الموقف الذي بدأنا فيه - لا يمكن لأحد أن يكون متأكدًا من الوضع القانوني الفعلي هو ، كما توافق بالقول:

أنا لا أقترح عليك أن تأخذ كلامي كضمان قانوني. كلانا يعلم أن تعليقاتي هنا لا تغير ترخيص React بحد ذاتها.

و:

سيتم ترخيص كل ما تعتقده على أنه الألياف الضوئية بموجب MIT.

لا يهم ما أعتقد أنه الألياف ، فهو يعتمد كليًا على ما يعرفه محامو Facebook وبراءات الاختراع المسجلة باسم Fiber.

لماذا يُقصد حاليًا من React Native أن يتم ترخيصها بشكل مختلف عن React ، عندما تشارك الكود مع React؟ ألا يؤدي ذلك إلى إبطال (العفو عن التورية) رخصة معهد ماساتشوستس للتكنولوجيا؟

ألاحظ أيضًا أنك لم تذكر GraphQL. هل فاتني شيء آخر؟

بيت القصيد من كارثة ترخيص React هو الافتقار إلى اليقين القانوني.

تضمين التغريدة

ألاحظ تعديلك ردًا على نقاطي:

لن تتضمن React أو تعتمد على أي كود مرخص بموجب BSD + براءات الاختراع أو أي منحة براءات اختراع أخرى تكرهها. نحن لا نزيل أجزاء من React. إن تبعية React الوحيدة غير المملوكة لـ FB والتي أعرفها هي تخصيص كائن وهو أيضًا تحت MIT.

لكنك قلت إنك ستزيل أجزاء من React ، وستقوم بفحص الكود "في الأيام القليلة المقبلة".

ستتوفر React وتبعياتها المملوكة لـ FB تحت إم آي تي ​​بمجرد أن يتاح لفريقنا الوقت الكافي لتنفيذ التغييرات

وأنت نسيت IANAL ... :-)

أوه ، في الواقع قلت ذلك بشكل طويل:

أنا لا أقترح عليك أن تأخذ كلامي كضمان قانوني. كلانا يعلم أن تعليقاتي هنا لا تغير ترخيص React بحد ذاتها.

مرة اخرى:

بيت القصيد من كارثة ترخيص React هو الافتقار إلى اليقين القانوني.

أتفق مع النقطة التي تقول إنه لا يوجد حتى الآن يقين قانوني. لكنني شخصيا أعتقد أن هذا الخيط قد انتهى ؛ من الأفضل وضع علامة عليها كمساهمين فقط ، والانتظار حتى يتم نشر الترخيص الفعلي ، ويمكن للفريق إجراء تقييمهم.

إلغاء الاشتراك الآن.

من فضلك لا تفريغ React ، اتخذ Facebook قرارهم https://thenextweb.com/dd/2017/09/25/facebook-re-licenses-react-mit-license-developer-backlash/

vinayakkulkarni بينما أفهم أن تكون شغوفًا بشيء ما ، فإنه ليس سببًا لإبداء تعليق كما فعلت. يجب أن تكون المساحة العامة (التي تتضمن تعليقات GitHub) مكانًا آمنًا لأي شخص. تشبيهك كان مسيئًا وعلى هذا النحو تم تعديله. في المستقبل ، يرجى التفكير في أن جميع الأجناس وجميع أنواع الأشخاص يستخدمون هذه المساحة وكيف أن ما تقوله قد يسيء إليهم.

sophiebits مجرد ملاحظة صغيرة لأقول شكراً

قد يكون هذا موضوعًا لموضوع جديد ، ولكن للأسف ترخيص MIT (حتى الترخيص القياسي) لا يزيل مشكلة "عدم اليقين" مع براءات الاختراع ، مما أدى إلى قرار WordPress سابقًا.

هل يمنحك ترخيص معهد ماساتشوستس للتكنولوجيا الحق في استخدام IP الحاصل على براءة اختراع؟ اقرأ ما يقوله المحامي عن ذلك: رخصة MIT ، سطراً بسطر

- فرانس بوما (FransBouma) 23 سبتمبر 2017

يبدو أن معهد ماساتشوستس للتكنولوجيا لا يمنحك ترخيص براءة اختراع. يمتلك Facebook براءات اختراع في React ، والتي تقول إنه يمنحك ترخيصها الحالي. مع الترخيص الحالي ، على الأقل تعلم أنك مُنحت أي تراخيص موجودة ، وتعرف الشروط التي تلغيها. مع MIT ، لا تحصل حتى على منحة الترخيص.

منح البراءات يعني أن هناك براءات اختراع معنية (أو ما الذي تمنحه؟). ماعدا لا أحد يعرف حتى ما هي براءات الاختراع. لم يخبر Facebook ، ولا حتى عندما منحته لهم ، ولا عندما أعلن عن إزالة المنحة.

بصرف النظر عما قد أعتقده شخصيًا أو فريق WordPress أن هذا يعني ، ما يبدو أنه لا يزال موجودًا هو الالتباس حول الوضع القانوني لبراءات اختراع Facebook (غير المدرجة) الموجودة على React ، والتي يستخدمها أي شخص [[قد - أو - قد لا]] داعي للقلق بشأن الانتهاك ، عند مقاضاة Facebook اليوم ، أو فقط باستخدام React بعد الترخيص الجديد.

مرة أخرى ، ربما أو لا ، المشكلة هي عدم اليقين ، وهذا ما أقترحه لم يتم حله.

للتذكير ، فإن الأغلبية التي قدمت رأيها في هذا الموضوع تريد حلاً يعتمد على Vue.

هناك عدة أسباب لذلك ، لا تقتصر على حقيقة أن Vue ليس لديه أي ارتباك في الترخيص (والذي لا يزال قائماً مع سياسة ترخيص Facebook من مستويين):

1. تم تصميم Vue من الألف إلى الياء لإضافته بشكل تدريجي ، مع جزر من الوظائف ، مما يسمح بالتحسين التدريجي لقاعدة الشفرة.

2. بالإضافة إلى ذلك ، وبشكل اختياري ، فإنه يوفر إدارة الحالة المدعومة رسميًا وحلول التوجيه.

3. وهو يدعم معالجات متعددة لـ HTML ، مما يتيح للمطورين اختيار لغة القالب - HTML ، JSX ، Pug ، إلخ ، أو وظائف العرض.

4. مكونات ملف واحد و CSS محدد النطاق (Stylus ، SASS ، SCSS ، PostCSS ، CSS Components) - بأسهل طريقة ممكنة. حرفيًا ، ما عليك سوى إضافة سمة النطاق إلى إعلانات نمط المكونات الخاصة بك ، وإتمامها.

5. دعم الخصائص المحسوبة (مع الذاكرة) المضمنة (أي بدون تبعيات مثل MobX).

   6+. أداء متفوق لـ React ، ومنحنى تعليمي أقل بكثير ، واعتماد أعلى في مجتمع PHP ، تحقق من Laravel Mix على سبيل المثال - يمكنك استخدام ذلك دون استخدام Laravel نفسه. أو قم فقط بتضمين Vue عبر https://unpkg.com/vue وابدأ الترميز.

Vue هو ببساطة أكثر ملاءمة لـ WordPress.

رد :

76364 جيثب ستارز
571 قضايا مفتوحة (!)
4325 قضايا مغلقة
178 طلبات سحب مفتوحة (!)
5644 طلب سحب مغلق

Vue :

68 ، 246 نجم جيثب (المسار هو تجاوز رد الفعل بحلول عيد الميلاد)
62 المشكلات المفتوحة (أكثر استجابة لإصلاح الأخطاء وإضافة الميزات المطلوبة)
5629 إصدارات تم إغلاقها
17 فتح طلبات السحب
863 طلب سحب مغلق

تضمين التغريدة

يبدو أن معهد ماساتشوستس للتكنولوجيا لا يمنحك ترخيص براءة اختراع. يمتلك Facebook براءات اختراع في React ، والتي تقول إنه يمنحك ترخيصها الحالي. مع الترخيص الحالي ، على الأقل تعلم أنك مُنحت أي تراخيص موجودة ، وتعرف الشروط التي تلغيها. مع MIT ، لا تحصل حتى على منحة الترخيص.

منح البراءات يعني أن هناك براءات اختراع معنية (أو ما الذي تمنحه؟). لم يخبر Facebook ، ولا حتى عندما منحته لهم ، ولا عندما أعلن عن إزالة المنحة.

هنا تكمن مشكلة المصدر غير المفتوح تمامًا من شركة كبيرة. في نهاية المطاف ، سيقوم محاموهم بإلغاء أي نوايا طيبة لفرق التطوير ، سواء الآن أو في المستقبل.

صاغ Facebook رخصة براءات الاختراع الخاصة بهم على أنها دفاع صارم عن "شيء أو أي شيء" ، والآن يُطلب منا الاعتقاد بأن "شيء أو أي شيء" لا يوجد بالفعل لـ React ، ولكن لا يزال موجودًا في React Native و GraphQL وما إلى ذلك.

هل يمكن أن تعد شركة Automattic بأنها ستتحمل عبئًا على نفسها وتحمل React ، fork ، وتطورها من تلقاء نفسها ، عندما يغير Facebook مرة أخرى ترخيصه ورأيه حول React؟

بالنسبة لي ، يبدو أن Facebook يضع فخًا لـ WordPress. 25٪ من جميع مواقع الويب في العالم هي صيد كبير.

يرجى وضع علامة على هذا الموضوع كـ _المساهمون فقط_ في أسرع وقت ممكن ، سيكون من الرائع قراءة أي نتيجة للمساهمين ، بدلاً من مجرد FUD والتكهنات ، دون الحاجة إلى إلغاء الاشتراك بالكامل. شكرا لك.

إن أصحاب المصلحة في WebReflection Wordpress ليسوا فقط مطوريها الأساسيين ، ولكن المجتمع الموسع أيضًا.

PericlesSouza الاستشهاد https://npmcharts.com/compare/react ، angular، @ angular / core ، ember-cli، vue

Vue ليس أكثر من مجرد صورة على الرادار. تستخدم الغالبية المذهلة React ولن تتفق بالتأكيد مع النقاط الخاصة بك أيضًا.

PericlesSouza الاستشهاد https://npmcharts.com/compare/react ، angular، @ angular / core ، ember-cli، vue

Vue ليس أكثر من مجرد صورة على الرادار. تستخدم الغالبية المذهلة React ولن تتفق بالتأكيد مع النقاط الخاصة بك أيضًا.

احصائيات NPM؟ هل تقصد نفس الإحصائيات التي يعترفون بها تحسب كل طلب فردي للتحقق مما إذا كنت تستخدم أحدث إصدار أم لا ، أو عبر كل تبعية ، كطلب للتنزيل؟ (لقد اعترفوا بذلك في مدونتهم عندما سخر الناس من مزاعم "مليارات الحزم شهريًا").

إذا كنت تريد أن تسلك هذا الطريق ، فإن الجميع يستخدم jQuery.

ربما جرب الأرقام الخاصة بالحزم التي لا تحتوي على حقل تشويه التبعية هذا:

https://npmcharts.com/compare/vue-cli ، إنشاء تطبيق تفاعل

صورة مختلفة تمامًا عن تلك التي اخترت تقديمها.

أو ماذا عن استخدام الموقع:

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

التي تدعمها إحصائيات BuiltWith:

أوه ، وسأترك هذه الصورة هنا - منذ أن سأل الفريق المجتمع أنفسهم. يجب أن تستمع إليهم بدلاً من معاملتهم بازدراء.

PericlesSouza ليس من المنطقي مقارنة vue-cli مع تطبيق create-react-app نظرًا لوجود أدوات بناء أخرى شائعة جدًا لـ React مثل GatsbyJS .
لا يستخدم العديد من مطوري React حتى CLI وبدلاً من ذلك يستخدمون نصوص Webpack المخصصة الخاصة بهم مثل Gutenberg و Calypso.

الحقيقة هي أن نظام React البيئي أكبر بكثير من نظام Vue. خذ على سبيل المثال المواد UI لVue.js التي لديها 4،339 النجوم بينما المواد UI لردة الفعل لديها 29078 النجوم.

مكون مربع تحديد أصلي يوفر وظائف مشابهة لـ Select2 بدون حمل عبء jQuery: يحتوي Vue select على 1،348 نجمة بينما يحتوي تحديد React على 8493 نجمة.

PericlesSouza ، drcmda ، يمكن الطعن في كل هذه البيانات بعدة طرق ، حتى إحصائيات npm باستخدام cli's ، إذا أضفت AngularCLI و EmberCLI ، فسترى بيانات مختلفة تمامًا ، والتي لا تعني شيئًا:

المصدر: https://npmcharts.com/compare/vue-cli ، create-reaction-app، @ angular / cli ، ember-cli

المصدر: https://w3techs.com/technologies/comparison/js-angularjs ، js-reaction، js-vuejs

المصدر: https://insights.stackoverflow.com/survey/2017#technology -frameworks-libraries-and-other-تكنولوجيز

ولكن لا ينبغي أن تكون هذه المحادثة حول الإطار الأكثر استخدامًا ، ولكن أيهما سيكون أفضل لبيئة Wordpress ككل.

PericlesSouzawillgm تنطبق القواعد على حد سواء. كلاهما يُحسب بالطريقة نفسها بالضبط ، من المخادع أن يزعم أنه ليس عدلاً. إن التشبث بمواقع CLI الاختيارية أو المواقع الموحية التي تحسب "إبداءات الإعجاب" و "النجوم" أمر غير مجدٍ. حتى نظام Stackoverflow شخصي للغاية ولم أسمع حتى عن موقع "builtwith ..." حتى اليوم ، وتعكس إحصائيات CLI عدد الأشخاص الذين يستخدمون CLI (الغالبية لا).

البيانات من المصدر الأكثر وضوحًا وأهمية ، والتي تعكس بيئات الإنتاج الحقيقية في ظل نفس الظروف الدقيقة ، هي الإحصاء الوحيد الذي لا يعجبني ، ولا يغير الطريقة التي هي عليه

ولكن لا ينبغي أن تكون هذه المحادثة حول الإطار الأكثر استخدامًا ، ولكن أيهما سيكون أفضل لبيئة Wordpress ككل.

وأنا أعتبر أنك تعرف أيهما أفضل. تعتقد أن 400.000 شخص يوميًا يحصلون على React خارج npm مخطئون. يمكن لـ Vue التنافس من تلقاء نفسه ، ولا يحتاج حقًا إلى حشد من الغوغاء يندفعون في تعقب المشكلات.

PericlesSouzawillgm تنطبق القواعد على حد سواء. كلاهما يُحسب بالطريقة نفسها بالضبط ، من المخادع أن يزعم أنه ليس عدلاً. إن التشبث بمواقع CLI الاختيارية أو المواقع الموحية التي تحسب "إبداءات الإعجاب" و "النجوم" أمر غير مجدٍ.

لا. تحتوي React على 16800 حزمة تابعة تحرف الأرقام. يعترف NPM بأن كل ما يعتبرونه تنزيلًا هو 200 رمز نتيجة عند استدعاء عنوان URL ، كنتيجة لفحص التبعية ، أو روبوت ، أو مرآة ، أو أي شيء. بالمناسبة ، يقولون أيضًا أن معظم التنزيلات في الصين ، حيث تحظى Vue بشعبية كبيرة ، تأتي من المرايا ولا يتم احتسابها.

بناءً على استخدامك للغة - "التشبث" ، "المواقع الموحية" ، "غير المجدية" ، ليس لديك أي حجج حقيقية حول هذا الموضوع ، بينما ، بناءً على طلب الفريق ، قمت بنشر إيجابيات استخدام Vue (انظر أعلاه ).

عد النجوم - يفعل الآخرون ذلك عند الإشارة إلى نجاح React ، لكنك تشجب قيمتها عند استخدامها للإشارة إلى شعبية Vue؟ أنت أيضًا لا تذكر عددًا أكبر بكثير من المشكلات المعلقة ( 571 ) ، والعدد الرائع جدًا من طلبات السحب المعلقة ( 178 ) التي لا تزال معلقة لـ React ، والتي عند مقارنتها بالاستجابة الأعلى لمجتمع Vue في إصلاح الأخطاء و إضافة ميزات ، هي سبب وجيه للقلق عند اقتراح استخدام React.

وهو ما يقودني إلى:

عد الإعجابات - حسنًا ، كان هذا هو بيت القصيد من هذا الموضوع ، كما بدأه الفريق وطلب من المجتمع - أعتقد أنك ببساطة لا تحب النتيجة. ها هي مرة أخرى ، وهي حاسمة للغاية:

لا. تحتوي React على 16800 حزمة تابعة تحرف الأرقام.

PericlesSouza كيف تصل إلى هذا الاستنتاج. هذا يعني ما يفترض أن تعنيه: أعلنت 16.800 حزمة أن React تعتمد عليها في package.json. ليست الروبوتات ، ولا الصين ، ... الحزم. يحتوي Vue على حوالي 2580 ، وهذا يعني أنه يحتوي على نظام بيئي وقاعدة مستخدمين أصغر بكثير. لماذا نتجادل حتى في هذا؟ ينعكس ذلك مباشرة من خلال احصائيات الاستخدام. التحديثات ، الأشخاص الحقيقيون أو الروبوتات ، تنطبق على كلتا الحزمتين. ما لم تفترض أن الروبوتات تتخطى Vue عمدًا لسبب ما.

لتمييز حزمة واحدة في جهاز تعقب يعامل كل حزمة بالطريقة نفسها ، لا معنى له. من ناحية أخرى ، فإن عد الإعجابات لا يعني شيئًا أكثر من أن المجتمع XY يعرف مكان التصويت.

تضمين التغريدة

أعتقد أن ما يعنيه هو أنه في كل مرة تقوم فيها بتثبيت حزمة تعتمد على React ، وتصل إلى NPM للتحقق من الإصدارات والتبعيات ، فإن NPM تعتبر ذلك على أنه download للحزمة ، حتى لو لم تكن كذلك تم تنزيله.

إذا كان هذا هو ما يعنيه ، فهو محق تمامًا ؛ نصت NPM صراحةً على أنهم يفعلون ذلك ؛ يصفون "منهجيتهم" على أنها "ساذجة عن قصد" (يذكرون أيضًا أن الروبوتات والمرايا يمكنها تحريف الأرقام نظرًا لعدم وجود آلية لتحديد الغرض من الطلب ، فهم يحسبونه فقط). وتحتوي React على حزم أكثر اعتمادًا ، وبالتالي يكون هذا التأثير أكثر وضوحًا.

بالنسبة للكثير من الحزم التابعة - نعم ، نظرًا لكون React إطارًا أقدم ، فإنه يحتوي على المزيد ، وهو يحتاج إليها نوعًا ما. أقوم بالتطوير باستخدام كل من React و Vue ، ومع Vue تميل إلى احتياج حزم إضافية أقل ، حيث أن النواة مكتملة تمامًا ، كما يتبع جهاز التوجيه الرسمي و Vuex فلسفة التبعيات المنخفضة. Vue نفسها لا تعتمد على أي حزم ، React تعتمد على القليل. لديهم نهج مختلفة في هذا الصدد.

مثال آخر هو أن الأشخاص يميلون إلى استخدام حزمة تكامل بين Bootstrap و React مثلاً ، أو استخدام مكتبات مثل عناصر النمط وأسماء الفئات وما إلى ذلك. مع Vue لا تحتاج إلى ذلك عمومًا ، على الرغم من وجود مثل هذه المشاريع أيضًا. أجد أن التعامل مع Vue أسهل كثيرًا حيث يمكنني الحصول على CSS خارج الصندوق بدون مكتبات أو تكوين إضافي ، ويمكنني كتابة عمليات التكامل البسيطة الخاصة بي مع أطر CSS حسب الحاجة ، بدلاً من استيراد مكتبة تكامل كاملة ثم تجربة الشجرة - هز 75٪ لست بحاجة.

PericlesSouza فاتك بعض العناصر ذات الصلة جدًا من

فتحات مسماة للسماح بمكونات القالب القابلة لإعادة الاستخدام مثل النماذج القياسية والمدخلات والتخطيطات وما إلى ذلك ، وهي أكثر مرونة من استخدام Reacts للأطفال.

المكونات الشرطية مع القدرة الاختيارية على الاحتفاظ بالحالة المحلية دون تدمير المكون غير النشط.

عنصر HTML "هو" بناء جملة مكون Vue لقوالب السلسلة ، والذي يمنع رفع عناصر HTML التي ينتج عنها HTML غير صالح.

تتدفق البيانات بطريقة واحدة مع الدعائم ، ولكن مع إضافة تدفق "بث" و "حدث ناقل" مبسط كثيرًا لإخطار أو تحديث الأخ أو الأب. يمكن أن يكون هذا مفيدًا للتواصل بين:

مثيلات Vue متعددة على الصفحة ، تتحكم في مناطق معينة. هذه التقنية مفيدة للوحات المعلومات الديناميكية أو عناصر واجهة المستخدم القابلة للتوصيل وإدارة الذاكرة.

المكون العالمي والمحلي والتوجيه المخصص التسجيل.

عوامل التصفية القابلة للتسلسل بالإضافة إلى الخصائص المحسوبة.

كل ما سبق جزء من مكتبة Vue الأساسية.

يُعد React إطار عمل رائعًا ، وأنا أستمتع باستخدامه ، لكنني شخصيًا أعتقد أن Vue أكثر ملاءمة لحالة الاستخدام المقترحة هذه.

mcquiggd

نعم ، لقد تم استعجالي ولم يكن لدي الوقت لإعداد قائمة كاملة بمزايا Vue.

من المثير للاهتمام أنك ذكرت أن لدى React تبعيات كما لاحظت أنها تعتمد على كل شيء بشأنه مثير للقلق خاصة عندما ترى قائمة المشاريع التي تعتمد عليها ، ولكن لها تراخيص مختلفة.

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

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

هدف

لتسهيل مشاركة Facebook واستهلاك JavaScript الخاص بنا.

ملحوظة: _إذا كنت تستهلك الكود هنا ولم تكن أيضًا مشروعًا على Facebook ، فاستعد لوقت سيئ_. _ يتم نشر هذه المكتبة مع وضع حالات الاستخدام في الاعتبار ولا يُقصد بالضرورة أن يستهلكها عامة الناس. ربما لن نتلقى طلبات الميزات الخاصة بك ما لم تتوافق مع احتياجاتنا.

571 قضايا مفتوحة (!)

إنها 338 الآن. (قضيت بضعة أيام في تنظيفها).

خلال الأشهر القليلة الماضية ، كان فريق React منشغلًا بإعداد إصدار React 16 جديد متوافق إلى حد كبير مع الإصدارات السابقة. كان هذا أكبر إصدار لنا على الإطلاق ، لذلك لم نكن رد فعل على أداة تعقب المشكلة ، لذلك أنا آسف لذلك. تبين أن React 16 حلت أيضًا مجموعة من هذه المشكلات. :-)

أريد أن أشير إلى أن معظم هذه القضايا الـ 338 المتبقية هي طلبات ومناقشات. يعطيني البحث عن ملصق الخطأ حوالي 60 مشكلة. ونظرًا لأن النظام البيئي لـ React أكبر من Vue في الوقت الحالي ، فليس من المستغرب أن يصطدم الأشخاص بمزيد من الحالات والتناقضات ويبدأون المزيد من المناقشات. كما أنهم يتوقعون أن يؤدي رد الفعل إلى تعويض المزيد من التناقضات في المتصفح ، لذا فإن العديد من الأخطاء مرتبطة بتغطية مفقودة لها. بالإضافة إلى ذلك ، نحتفظ بالوثائق في نفس المستودع ، لذا فإن مجموعة من هذه المشكلات تتعلق بالمستندات.

آمل أن يمنحك هذا نظرة ثاقبة عن سبب ميلنا إلى زيادة عدد المشكلات عن Vue.

من المثير للاهتمام أنك ذكرت أن لدى React تبعيات كما لاحظت أنها تعتمد على fbjs. أضفت بعض التركيز على الأجزاء التي يجب أن تدق أجراس الإنذار إذا كان الناس يفكرون في React ، مع إستراتيجية ترخيص مستويين على Facebook أثناء مشاركة الكود بين المشاريع المرخصة بشكل مختلف. تلميح إلى أن كل شيء بشأنه مقلق خاصة عندما ترى قائمة المشاريع التي تعتمد عليها ، ولكن لها تراخيص مختلفة.

لسوء الحظ هذا فود لا أساس له لست متأكدًا من دافعك لنشرها ، ولكن

يمكنك أن ترى بنفسك أن ترخيص fbjs قد تم تغييره أيضًا إلى MIT في https://github.com/facebook/fbjs/commit/c69904a511b900266935168223063dd8772dfc40 قبل خمسة أيام من تعليقك. إصدار React 16 الذي تم إصداره قبل أيام قليلة لا يحتوي على بايت واحد غير MIT.

حقيقة أن المشاريع الأخرى تعتمد على fbjs ولكن لها ترخيصًا مختلفًا هي حقيقة غير ذات صلة تمامًا ، تمامًا كما هو غير ذي صلة أن رمز التطبيق الخاص بك ربما ليس MIT ولكنه يعتمد على Vue.

ملاحظة: أعتقد أن Vue رائع ، ولا أريد الضغط على React لأي شخص. لكني أريد أن أتأكد من أننا نبني هذه المناقشة على الحقائق. :-) نحن دائمًا منفتحون على النقد ، وأنا متأكد من أن كل من Vue و React لديهما أشياء يمكن تعلمها من بعضهما البعض.

كل هذا حديث مثير.

يجب أن أسأل - لماذا الإطار / المكتبة على الإطلاق؟ كما ذكرنا سابقًا ، يبدو أن معيار Web Component يوفر ما تم تصميمه من ReactJS و Vue وغيرهما (حيث لم يكن المعيار موجودًا).

يمكنك استخدام مكتبات الحالة مثل Redux بشكل جيد مع مكونات الويب. مماثلة مع مكتبات التوجيه. لم يتم تطوير SSR تمامًا باستخدام Web Components ، ولكن هناك أشخاص يعملون هناك أيضًا. تتمثل أكبر قيمة لـ React جزئيًا في المكتبات الداعمة المتنوعة المحيطة بها - والتي لا تُفقد بالضرورة باستخدام النظام الأساسي.

ما الذي يوفره لك إطار عمل XXX عبر مكونات الويب الخاصة بالنظام الأساسي؟

كلام مثير حقا ...

الترخيص الرابع لـ React ، حتى الآن.

1. في الأصل Apache 2.0. كان يجب أن يكون بخير ، أليس كذلك؟ ما هي المشكلة؟
2. ثم BSD + براءات الاختراع. دون الكشف عما تفعله براءات الاختراع أو لا توجد.
3. ثم تعديلات طفيفة ، يزعم أنها ترضي جوجل. بدون أي تفاصيل عن السبب.
4. الآن MIT ، مع إعادة هيكلة غير محددة لـ React ، ولكن ليس للمشاريع ذات الصلة مباشرة ، مثل React Native و GraphQL وما إلى ذلك ... والاعتماد المشترك مع الوصف العام "لتسهيل مشاركة Facebook واستهلاك JavaScript الخاص بنا. في الأساس ، سيسمح لنا هذا بشحن الكود دون الحاجة إلى القلق بشأن مكان وجوده "

كل هذا على ما يبدو ، لا داعي للقلق على الإطلاق.

[تمت إزالة التعديل بواسطة Tammie Lister: وسائل الشرح الشخصية مثل هذه غير مقبولة]

PericlesSouza يمكنك القول بأنه لا ينبغي الوثوق بنا لأن التراخيص كانت مربكة من قبل. هذا صحيح إذا كانت حجتك. لكن لا ينبغي أن تكون التراخيص مربكة الآن.

React هو MIT.
تبعية fbjs هي MIT.
الكود الذي تشاركه React و React Native (والذي كان ولا يزال موجودًا في React repo) هو MIT.
React ، بما في ذلك كل تبعياتها ، هو MIT.
إن إنشاء تطبيق React ليس ضروريًا لاستخدام React ، ولكنه أيضًا MIT.
Relay و graphql-js ليست ضرورية لاستخدام React ، لكنها أيضًا من MIT.

أصدرنا React 16.0 مع الترخيص الجديد. من السهل التحقق من ذلك.
أصدرنا أيضًا إصدارًا جديدًا من React 15.x بترخيص MIT كـ 15.6.2.
نحن نخطط لإصدار جميع الإصدارات المستقبلية من React بموجب ترخيص MIT أيضًا.

أضف إلى ذلك ، اعترف موظف آخر على Facebook في هذا الموضوع بأن React (MIT for 16؟ What for <16؟ 17+؟ لإزالة هذا البيان ، بعد أن نقلت عنه).

أنا ذلك المهندس. (لها.)

لقد علّقت على https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331737418 ، ثم أجبت https://github.com/WordPress/gutenberg/issues/2733#issuecomment -331738521.

هذا هو المحتوى الأصلي لتعليقاتنا ، كما هو مسجل في عميل البريد الإلكتروني الخاص بي:

ها هو المحتوى في هذه اللحظة:

بعد أن أدليت بتعليقي ، قمت بتحرير تعليقك ليكون أطول بكثير ، بما في ذلك السؤال الإضافي:

ما الأجزاء التي تتم إزالتها للسماح بنشر React تحت MIT؟

الذي لم يكن في تعليقك الأصلي. لذا رداً على تعديلك ، قمت بتحرير تعليقي لأضيف:

نحن لا نزيل أجزاء من React. إن تبعية React الوحيدة غير المملوكة لـ FB والتي أعرفها هي تخصيص كائن وهو أيضًا تحت MIT.

الذي كنت تعتقد أنه من المناسب بعد ذلك الاتصال بي في التعليق التالي. كيف أجرؤ على تعديل تعليقي لمعالجة سؤال أضفته في تعديلك. لم أقم بإزالة أو تحرير أي ادعاء حول شفرة مشاركة React و React Native.

-

من فضلك توقف عن انارة الغاز لي. انها مرهقة.

youknowriad هل ستكون لطيفًا بحيث تغلق هذا الموضوع؟ لا أستطيع أن أتخيل أي مناقشة أكثر إنتاجية تحدث هنا.

إذا كان أي شخص آخر هنا قلقًا بشكل قانوني بشأن الترخيص لا يزال ، فلا تتردد في مراسلة DM لي وسأبذل قصارى جهدي للتوضيح.

الذي كنت تعتقد أنه من المناسب بعد ذلك الاتصال بي في التعليق التالي. كيف أجرؤ على تعديل تعليقي لمعالجة سؤال أضفته في تعديلك. لم أقم بإزالة أو تحرير أي ادعاء حول شفرة مشاركة React و React Native.

من الواضح أنني رددت على تعديلك ، هل هذه مشكلتك؟

ليست هناك حاجة إلى إضاءة الغاز ، ببساطة الانفتاح والاتساق من Facebook وفريق تطوير React والترخيص ، وكما تشير نماذج الترخيص الأربعة في Reacts إلى فترة حياة قصيرة نسبيًا ، ومشاركتك (الحالية) ، للأسف ، هذا غير موجود.

وضع الترخيص جانبًا بإيجاز: مرة أخرى ، ما الذي تقدمه React اليوم والتي يتم اكتسابها بشكل يتجاوز مكونات الويب؟ بافتراض أنك ستستمر في استخدام مجموعة مختارة من المكتبات الداعمة في كليهما (مثل Redux).

باستخدام Web Components ، يمكن لـ WordPress إنشاء العديد من العناصر التي يمكن استخدامها عبر العديد من أطر / مكتبات الواجهة الأمامية. سيسمح هذا للمستخدمين النهائيين باستخدام React أو Vue أو Angular أو أي واجهة أمامية يستخدمونها "لإسقاط" مكونات WordPress.

sophiebits لست متأكدًا من إصدار

@ بريان ماكبرايد

لقد أوضحت نقطة جيدة ، وأعتقد أنها أثيرت في وقت سابق في الموضوع - "لماذا لا تستخدم جافا سكريبت الفانيليا" ، على أساس المعايير ، ومتوافق بالكامل

همم.

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

كما قلت للناس ، كن حذرًا جدًا بشأن التحكم في الإصدار إذا كنت تستخدم React.

نعم ، ارتكبنا عن طريق الخطأ ثلاثة ملفات برأس خاطئ ، من طلبات السحب التي كانت مفتوحة قبل تغيير الترخيص. لم يكن أي منها في نسخة تم إصدارها (ولا يمكن أن تكون - كان أحدهما اختبارات وحدة ، واثنان كانا جزءًا من موقع الويب).

الأخطاء تحدث. قمنا بإصلاحه عندما اكتشفنا وأضفت برنامجًا نصيًا إلى CI الخاص بنا للتحقق في المستقبل من عدم إضافة المزيد من المراجع العرضية. يمكنك أن ترى ذلك في هذا الالتزام.

هناك شيء إضافي أعتقد أنه يجب على مشاريع البرمجيات الحرة مراعاته - يستفيد Facebook من استخدام React.

لكن قيم Facebook عمومًا لا تتماشى مع قيم حركة البرمجيات الحرة - كل شيء بدءًا من التلاعب غير الأخلاقي بالمستخدمين إلى الهجمات على حياد الشبكة ("الأساسيات المجانية") ، وعدم القدرة على حذف البيانات ، وعدم القدرة على منع جمع البيانات ، والرقابة ، والحدائق المسورة وغرف الصدى والمزيد.

يشبه [Facebook] عندما اعتاد أخي أن يجعلني ألكم نفسي وأسأل ، "لماذا تضرب نفسك؟" ثم أخبر والدتي أنه لم يكن خطؤه.

نظرًا لأنني شاهدت Facebook على مدار سنوات عديدة ، اقتربت بشكل متزايد من استنتاج أنني لم أعد أرغب في دعم تلك الشركة بأي شكل من الأشكال ، لذلك أنا شخصياً لا أستخدم برنامج FB كلما وجدت بدائل.

قرأت كتابًا على React ويبدو رائعًا من منظور البرمجة - لكن البدائل رائعة أيضًا ، ولا تأتي مع عبء دعم Facebook.

أعتقد أن مشاريع البرمجيات الحرة يجب أن تفضل دائمًا مكتبات برمجيات حرة مستقلة متى توفرت. هناك الكثير من البدائل الرائعة لبرنامج WordPress ، بما في ذلك Vue ومكونات الويب و Ember و Mithril. يحظى Vue بدعم كبير في مجتمع PHP وليس لديه أي مشاكل أخلاقية مرتبطة به ، لذلك يبدو أنه مناسب تمامًا. إذا كان الأمر يتعلق فقط بلوحة القيادة ، فقد يكون من المفيد إلقاء نظرة على شيء أكثر إثارة للاهتمام من JavaScript: Elm .

لا ينبغي أن يتعلق الأمر بما هو عصري أو رائع في الوقت الحالي ، ولكن يجب أن يكون حول ما يوفر أكبر قدر من الحرية التكنولوجية للأجيال القادمة - بشكل مباشر أو غير مباشر.

مجرد فكرة أخرى للنظر ...

شكرًا لكل من عبروا عن آرائهم أثناء محاولتهم إجراء محادثة محترمة. أود أيضًا أن أضيف شكرًا خاصًا إلى sophiebits و gaearon و @ blake-newman وكل شخص آخر يمثل المشاريع الذين قضوا وقتهم في الإجابة على الأسئلة. إن معرفتك موضع تقدير كبير ، ومرحب بها دائمًا.

انتقلت المحادثة منذ ذلك الحين إلى اجتماعات JavaScript في قناة # core-js Slack ، وهناك ملخص جيد هنا . إذا كنت مهتمًا بالمشاركة في هذه المناقشات ، فإننا ندعوك للانضمام إلينا هناك. بدلاً من ذلك ، لدينا طريقتان للتشغيل البيني يمكن أن تستخدم المساهمات والاختبار والتغذية الراجعة: # 2463 و # 2791.

وبهذا يكون هذا الخيط قد أخذ مجراه. نحن نغلق المشكلة ، لكننا نشجعك على مواصلة المحادثة في الأماكن المذكورة أعلاه.

لقد أثمر هذا الموضوع بعض النقاش الجيد ، لكن بعضًا منه أظهر سلوكًا غير مقبول وتم تعديله. من المهم أن تتذكر أن https://wordpress.org/about/etiquette/ ينطبق على أي مشروع WordPress ولن نتسامح مع الانتهاكات أو تلك التي ترتكبها. شكرًا لكم جميعًا من ساهم في المحادثة بطريقة مراعية ومحترمة.