لوحة المتصدرين

من أهم الأمور التي ينبغي على مطور ووردبريس الإلمام بها ومعرفتها هي قاعدة بيانات ووردبريس حيث أنها المستودع الرئيسي للبيانات في نظام إدارة المحتوى كما أنها تعكس التركيبة الخاصة بووردبريس وأهم محتوياته الأساسية وطريقة تمديده بصورة مثالية ويظهر هذا جليًَا عند اطلاعنا على جداول meta في الفقرات القادمة. في هذا المقال سنحاول تقديم نبذة عن جداول قاعدة بيانات ووردبريس ودور كل جدول بالإضافة لأهم محتوياته وارتباطه بالجداول الأخرى، بالإضافة إلى ذكر بعض الطرق التي يوفرها ووردبريس للتعامل مع البيانات. جداول قاعدة بيانات ووردبريس انقر على الصورة لمُشاهدتها بحجمها الكامل هذا التفصيل الذي سنذكره قد لا تجده حتى في التّوثيق الرّسمي لووردبريس وبالتالي سيكون مرجعًا مُفيدًا لمن أراد دراسة قاعدة البيانات بتعمّق. جدول wp_optionsتطرقنا من قبل لهذا الجدول في مقال استقبال وحفظ الخيارات حيث ذكرنا أنّ ووردبريس يستخدمه لحفظ الخيارات الخاصة به وكذلك يتيح لك حفظ خيارات القوالب أو الإضافات التي تبرمجها فيه من خلال توفير الواجهة البرمجية للإعدادات والتي أسهبنا في الكلام عنها في المقال آنف الذّكر. يحتوي هذا الجدول على أربعة أعمدة وهي option_id، option_name, option_value, autoload وهي نفس المعاملات التي تقوم بتمريرها للدّالة add_options التي تكلّمنا عنها سابقا. لا يرتبط هذا الجدول بصورة مباشرة بأيّ من الجداول الأخرى في قاعدة البيانات. جدول wp_usersكما هو واضح من اسمه خاص بحفظ بيانات المستخدمين لموقع ووردبريس بجميع رتبهم سواء تعلّق الأمر بالمدير admin أو بغيره من الرّتب. هذا الجدول مكون من عشرة أعمدة وهي: ID: وهو المعرف الخاص بالمستخدم، ويجب أن يكون فريدًا وهو المفتاح الرئيسي للجدول Primary key. user_login: اسم المستخدم أو اسم الدخول. user_pass: كلمة مرور المستخدم وتحفظ مشفرة في قاعدة البيانات. user_nicename: الاسم اللطيف للمستخدم. user_email: البريد الإلكتروني للمستخدم. user_url: الموقع الإلكتروني للمستخدم. user_registered: تاريخ تسجيل المستخدم. user_activation_key: المفتاح المستخدم عند استعادة كلمة المرور، يقوم ووردبريس بتوليده عند طلب استعادة المرور ويقوم بمسحه بعد استعماله مباشرة. user_status: تم التخلي عن هذا العمود deprecated وربما يتم إسقاطه في النسخ القادمة من ووردبريس. display_name: اسم العرض للمستخدم والذي يظهر في واجهة الموقع. جدول المستخدمين مرتبط بعدة جداول في قاعدة بيانات ووردبريس حيث يرتبط بجدول المقالات لأن كل مقال يكون منسوبًا لكاتب (مستخدم) معين، وكذلك مرتبط بجدول التّعليقات لنسبة كل تعليق لكاتبه إن كان من المُسجًّلين في الموقع، وأخيرًا يرتبط بجدول wp_usermeta وهو الجدول التالي في شرحنا. جدول wp_usermetaكما رأينا فإن جدول المستخدمين مكون من أعمدة مُحدّدة بالتّالي عندما تحتاج لإضافة بيانات معينة للمستخدم مثل روابطه في الشبكات الاجتماعية مثلًا ستضطر إلى إضافة المزيد من الأعمدة في جدول المستخدمين لكن هذه الطريقة غير عملية لذلك يأتي جدول wp_usermeta ليُمكّنك من إضافة المزيد من البيانات meta للمستخدمين بدون التعديل على تركيبة الجداول (الأعمدة) وبإضافة المزيد من الصفوف لهذا الجدول. يحتوي هذا الجدول على أربعة أعمدة وهي umeta_id: وهو المعرف الخاص بهذه الـmeta التي تريد إضافتها وهو فريد حيث أنه المفتاح الرئيسي لهذا الجدول. user_id: معرف المستخدم الذي تعود له هذه البيانات meta وهو عبارة عن مفتاح أجنبي foreign key يعود إلى جدول wp_user وبهذه الطريقة يتم الربط بين الجدولين كما هو معلوم في قاعدة البيانات العلائقية Relational Database. meta_key: مفتاح البيانات meta (اسمها) والذي يتم استدعاؤها به برمجيًّا حيث أن لكل meta مفتاح وقيمة كما هو في الخيارات. meta_value: قيمة البيانات meta. هذه الطريقة المستخدمة في إضافة المزيد للبيانات للمستخدمين بدون التعديل على جدول wp_user وذلك من خلال إتاحة جدول wp_usermeta مستخدمة أيضا مع المقالات post والتعليقات comment حيث يستخدم جداول غير الجداول الأساسية لإضافة بيانات غير البيانات الأساسية لكل من المقالات والتعليقات كما سنرى في الفقرات التالية، ولعل الفكرة العامة لهذه الطريقة وضحت من خلال الجدول الأساسي wp_user وجدوله المساعد wp_usermeta. جدول wp_postsيمكن أن نعتبر هذا الجدول هو الجدول الأساسي في ووردبريس حيث أنه الرّكيزة الأساسية لأنواع المقالات والتي يمكن أن نعتبرها المحتويات في نظام إدارة المحتوى، أي أنها العنصر الأساسي الذي تم من أجله إنشاء النظام. تجدر الإشارة أن هذه الجدول ليس مُختصًّا بالمقالات فقط بل بكل أنواع المقالات والتي تشمل الصفحات أيضا وأي نوع مقالات أخر يتم إنشاؤه، وإن كنت لم تتطلع من قبل على أنواع المقالات المخصصة فأشير إليك بقراءة هذا المقال المختصر عن أنواع المقالات المُخصّصة في ووردبريس. يحتوي هذا الجدول على ثلاثة وعشرين عمودًا وإليك تفاصيلها ID: معرف فريد للمقال. post_author: كاتب المقال. post_date: تاريخ المقال. post_date_gmt: تاريخ المقال بتوقيت جرينتش. post_content: محتويات المقال (النّصّ الفعلي للمقال). post_title: عنوان المقال. post_excerpt: مُقتطف المقال (نصّ اختياري يمكن للمستخدم أن يدخله). post_status: حالة المقال (منشور، مسودة، تحت المراجعة، ... الخ). comment_status: حالة التّعليقات (هل التعليقات مفتوحة أم مغلقة). ping_status: حالة التّنبيه (هل التنبيهات مفعلة أم لا). post_password: كلمة مرور للمقال (في حالة كان مغلقا بكلمة مرور). post_name: رابط المقال أو ما يسمى بالاسم اللطيف. to_ping: روابط المقالات التي سيتم تنبيهها (أي المشار لها في المقال الحالي) وهذه لي حالة أن المقال لم ينشر بعد. pinged: روابط المقالات التي تم تنبيهها وهذه في حالة أن المقال قد تم نشره. post_modified: تاريخ آخر تعديل للمقال. post_modified_gmt: تاريخ آخر تعديل للمقال بتوقيت جرينتش. post_content_filtered: تستخدم لتخزين نسخة cache لـpost_content المشار لها سابقا (عادة بعد تطبيق الخطافات المرتبطة بالمُرشح the_content عليها). post_parent: معرف المقال الأب لهذا المقال (في حالة كان نوع المقالات هرمي hierarchical مثل الصّفحات. guid: اختصار لـGlobal Unique Identifier وهي عبارة عن الرابط الحقيقي للمقال. في حالة الصفحات يكون هذا هو الرابط الفعلي إمّا في حالة الملفّات المرفقة attachments يكون هذا هو الرابط للملف المرفق. menu_order: قيمة عددية (0، 1، 2، ...) تُحدّد ترتيب المقال وتعمل مع أنواع المقالات الهرمية مثل الصفحات وليس المقالات العادية. post_type: نوع المقال (مقال، صفحة، منتج، ملف مرفق، ..الخ). post_mime_type: تعمل فقط مع الملفات المرفقة attachments حيث تحتوي على نوع الميديا للملف MIME type. comment_count: عدد التعليقات مضاف إليه عدد التنبيهات pings والتعقيبات trackbacks. يرتبط جدول المقالات wp_posts مع مجموعة من الجداول وهي جدول wp_user: كما تم الإشارة إلى هذا الأمر سابقا حيث أن لكل مقال كاتب. جدول التعليقات wp_comments وهذا واضح ليربط كل مقال بالتّعليقات عليه. جدول wp_term_relationships وسيتم شرح هذا في الفقرات القادمة. جدول wp_postmeta: وهو الجدول التّالي في شرحنا جدول wp_postmetaكما هو الأمر بالنسبة للمستخدمين قد تحتاج لإضافة المزيد من البيانات للمقال غير البيانات الأساسية الموجودة في جدول المقالات wp_post فمثلا إذا كان لديك نوع مقالات يُسمّى منتجات قد تحتاج لإضافة بيانات إضافية لكل منتج مثل السّعر والكمّيّة المُتوفّرة وغيرها من البيانات وكما هو الحال بالنسبة للمستخدمين يتم استخدام جدول إضافي وهو جدول wp_postmeta لإضافة مثل هذه البيانات وربطها بالمقال المعين. يتكون هذا الجدول من أربعة حقول وهي meta_id: وهو المعرف الخاص بهذه الـmeta التي تريد إضافتها وهو فريد حيث أنه المفتاح الرئيسي لهذا الجدول. post_id: معرف المقال الذي تعود له هذه البيانات meta وهو عبارة عن مفتاح أجنبي foreign key يعود إلى جدول wp_post وبهذه الطريقة يتم الربط بين الجدولين. meta_key: مفتاح البيانات meta (اسمها) والذي يتم استدعاؤها به برمجيًّا حيث أن لكل meta مفتاح وقيمة كما هو في جدول wp_usermeta. meta_value: قيمة البيانات meta. يرتبط هذا الجدول بجدول المقالات wp_posts فقط. جدول wp_commentsوكما هو واضح من الاسم هذا هو الجدول الذي يتم فيه حفظ التعليقات، وله مجموعة من الحقول لن نتطرق لها الآن حتى لا نطيل الشرح كما أنه يمكنك الاطلاع عليها في الصورة أعلاه. يرتبط هذا الجدول بجدول المستخدمين wp_users إذا كان التعليق من مستخدم مسجل في الموقع، كما يرتبط بالطّبع بجدول المقالات حيث أن التعليق يعود لمقال معين حيث يكون معرف المقال ID هو المفتاح الأجنبي والذي يقوم بعميلة الربط. أيضا يرتبط هذا الجدول بجدول wp_commentmeta وهو الجدول التالي في الشرح. جدول wp_commentmetaومثل هذا الجدول والعلاقة التي تربطه بجدول wp_commetnts هو مثل العلاقة بين كل من wp_posts و wp_postmeta وكذلك wp_users و wp_usermeta. وأظن أن الصورة قد أصبحت واضحة بالنسبة لهذه الطريقة التي يستخدمها ووردبريس في الربط بين البيانات. جدول wp_linksيستخدم لحفظ البيانات المتعلقة بميزة الروابط links والتي أصبحت ملغية deprecated ورغم أنه يمكنك إعادة تفعيلها من خلال إضافة Link Manager إلا أننا لن نتطرق لشرح هذا الجدول (حتى الإضافة لم تحدث منذ أكثر من عامين). جدول wp_term_taxonomyهذا الجدول يُعرّف العلاقة بين ما يسمى بالفئات أو الأنواع Taxonomies والـterms الموجودة في الموقع. كل نوع Taxonomy عبارة عن طريقة لتنصيف المقالات وفق شيء معين، مثلا يأتي ووردبريس بعدة أنواع افتراضية منها التصنيفات والوسوم وهما للمقالات، لكن يمكنك إضافة المزيد من الأنواع لأي نوع من أنواع المقالات طالما أنه يدعمها. كل واحد من الأنواع (الوسوم مثلا) يحتوي على عدد من الـterms وهي عبارة عن الوسوم نفسها وكل وسم يحتوي على عدة مقالات أو يمكن أن نقول أن كل مقال له عدة وسوم وكذلك عدة تصنيفات وهكذا يكون المقال له عدد من الـterms. إذن يمكن أن نعتبر أن كل نوع Taxonomy عبارة عن أب أو طريقة لتجميع عدد من الـterms أو أن كل term يتبع لنوع معين. الصورة التالية توضح مفهومي الأنواع Taxonomies وكذلك الـTerms والعلاقة بينهما انقر على الصورة لمُشاهدتها بحجمها الكامل هذا الجدول يحتوي على ستة أعمدة وهي term_taxonomy_id: معرف العلاقة بين النوع Taxonomy والـterm. term_id: معرف الـterm (مثلا 1 أو 7). taxonomy: اسم النوع الذي يتبع له هذا الـterm (مثلا تصنيفات أو وسوم). description: وصف للعلاقة. parent: الأب لهذا الـterm. count: عدد المقالات في هذا الـterm. هذا الجدول يرتبط بجدولي wp_term_relationships وwp_terms التّاليين. جدول wp_termsهذا الجدول يعرف فيه الـterms (مثلا التصنيفات أو الوسوم) الموجودة في الموقع ويرتبط بالجدول السابق ليربط كل term مع النوع taxonomy الخاص به. يتكون هذا الجدول من أربعة عمدة هي term_id: معرف الـterm وهذا هو المفتاح الأساسي لهذا الجدول. name: اسم الـterm. slug: الاسم اللطيف للterm. term_group: هذا العمود مضاف لإضافة خاصية تسمح بوجود عدة مسميات لنفس الـterm لكن يبدو أن هذه الخاصية لم تدعم حتى الآن في ووردبريس، وهذا وفقا لأحدى الإجابات على موقع Stack Exchange . جدول wp_term_relationshipsلاحظ أنّه في الجدولين السّابقين كان التركيز على كل من الـterms والأنواع والعلاقة بينهما لكن حتى الآن ليس هنالك ربط فعلي بين التصنيفات والمقالات وعموما بين الـterms والمقالات، وهذه مهمة هذا الجدول حيث يربط المقالات مع معرف جدول wp_term_taxonomy والذي كما ذكرنا يعرف العلاقة بين الأنواع والـterm التابعة لها. يتكون هذا الجدول من أربعة أعمدة هي object_id: وهو معرف المقال الذي يراد ربطه بالـterm الخاص به وهذا هو المفتاح الأساسي لهذا الجدول. term_taxonomy_id: وهو عبارة عن مفتاح أجنبي عبارة عن المفتاح الأساسي في جدول wp_term_taxonomy. term_order: ترتيب الـterm. هذا الجدول بالطّبع يرتبط مع جدولي wp_posts وكذلك جدول wp_term_taxonomy وأيضا يرتبط مع جدول wp_links الذي ذكرنا أنه أصبح deprecated. التعامل مع قاعدة بيانات ووردبريسبالطبع يمكنك استخدام دوال my_sqli الأساسية المتاحة مع لغة php للتّواصل مع قاعدة البيانات أو حتى استخدام فئة PDO لكن يفضل دوما استخدام الطرق التي يقدمها ووردبريس ما دام ذلك مُمكنًا للحصول على توافقية أكبر للإضافة مع بقية مكونات ووردبريس بالإضافة للاستفادة من الفئات والتسهيلات التي يوفرها ووردبريس، وإليك طريقتين يُوفرهما ووردبريس للتعامل مع قاعدة بياناته: 1- استخدام الحلقة The Loopهذا المصطلح في ووردبريس يرمز لأحد أهم المكونات في ووردبريس والتي تستخدم بكثرة في تطوير قوالب ووردبريس، وهي ببساطة طريقة لجلب المقالات (أو أنواع المقالات المخصصة) وعرضها في القالب أو الإضافة وهذه هي الصورة العامة للحلقة <?php if ( have_posts() ) : // التحقق من وجود المقالات ?> <?php /* بدء الحلقة */ ?> <?php while ( have_posts() ) : the_post(); // تجهيز بيانات المقال ?> // هنا يتم استخدام وسوم القالب لجلب البيانات المتعلقة بالمقال الحالي // لاحظ أن ما بداخل الحلقة يتكرر في كل مرة حتى يصل إلى عدم تحقق الشرط في السطر الأول <?php endwhile; ?> <?php endif; ?>داخل الحلقة يتم استخدام بعض الدّوال التي يوفرها ووردبريس والتي تسمى بوسوم القالب Template Tags وهي عبارة عن دوال جاهزة تستخدم لجلب بيانات المقال والبيانات المرتبطة به مثل اسم الكاتب وتصنيفات المقال وغيرها من المحتويات. إذن استخدام الحلقة يوفر لنا إمكانية استخدام مجموعة كبيرة جدا من الدّوال الجاهزة التي توفر كثيرا من الجهد والوقت. يمكن أن نقول أن هنالك نوعان من الحلقات، الأولى هي الحلقة الأساسية التي مثلنا لها أعلاه والثانية يمكن إنشاؤها عن طريق إنشاء كائن Object من الفئة WP_Query بالصورة التالية: <?php $args = array(); // هنا يتم تعريف المعاملات التي ستمرر في الأسفل ?> <?php $query = new WP_Query($args); // تعريف الكائن الذي سيستخدم لجلب المقالات في الحلقة ?> <?php if ( $query->have_posts() ) : // التّحقق من وجود المقالات ?> <?php /* بدء الحلقة */ ?> <?php while ( $query->have_posts() ) : $query->the_post(); // تجهيز بيانات المقال ?> // ما بداخل الحلقة مشابه للحلقة الأساسية <?php endwhile; ?> <?php endif; ?>عند إنشاء الكائن تقوم بتمرير بعض المعاملات التي تحدد لووردبريس المقالات التي تود جلبها فمثلا قد ترغب بجلب جزئية فقط من المقالات والتي تُحقّق شرطًا مُعيّنًا مثل المقالات التّابعة لتصنيف مُعيّن وهكذا، وهذا أيضا ينطبق على أنواع المقالات المُخصّصة حيث تُمرر نوع المقالات المُخصّصة الذي تود جلبه بالإضافة لبقية المعاملات التي تود تمريرها. بالطبع فإن الحلقة محدودة على جلب البيانات المُتعلّقة بالمقالات وأنواع المقالات المُخصّصة بالتّالي لن تستخدمها إلا عندما تود جلب هذا النوع من البيانات وإلا فستنتقل إلى طريقة أخرى، لكن طالما أنّك تود جلب هذا النوع من البيانات فلا تعدل عن استخدام الحلقة أو على الأقل استخدام الدالة get_posts التي تشبه الحلقة في معاملاتها لكنها ترجع البيانات في شكل مصفوفة. 2- استخدام صنف wpdbهذا الصّنف يحتوي على مجموعة من الدّوال يستخدمها ووردبريس في التعامل مع قاعدة بياناته، ويمكنك الوصول لهذه الدّوال من خلال استخدام الكائن $wbdb وهو عبارة عن global object وهذا مثال لطريقة استخدامه global $wpdb; $results = $wpdb->get_results( 'SELECT * FROM wp_options WHERE option_id = 1', OBJECT );تستطيع من خلال هذا الكائن الوصول إلى مجموعة كبيرة من الدّوال التي يوفّرها الصّنف wpdb، كما تستطيع أيضا الوصول إلى متغيرات هذا الصّنف والتي من ضمنها جداول قاعدة البيانات التي ذكرناها سابقا. هل تفضل استخدام طريقة أخرى إذا كان الأمر كذلك فلا تنس التّحقق الجيد من البيانات قبل إدخالها واسترجاعها من قاعدة البيانات، حتى لا تحتوي الإضافة على ثغرات أمنية تسهل من اختراق الموقع. خاتمةيمكن أن نقول أننا أنهينا الجانب النّظري لبعض أساسيات ووردبريس لمطوري الإضافات، ولم يتبق لنا سوى تقديم مثال عملي لإضافة حقيقية يربط هذه المفاهيم التي تعرفنا عليها ويوضّحها بصورة أكبر، وهذا ما سنقدمه في المقال القادم إن شاء الله.

هناك اعتقاد خاطئ بين العديد من مطوّري الويب أن CSS هي الطريقة الوحيدة للقيام بالتحريك Animations. برزت CSS بقوة كأكثر نظام مُدلّل خلال سنوات وحتى الآن، وتحدّث المطوّرون باستمرار حول متانتها وتوافقها مع الهواتف. CSS جيدة لكنها ليست أفضل من جافاسكربت. هناك بعض الأساطير حول CSS قادت المطوّرين بشكل استباقي لتبنّي هذا النظام (أي CSS) والتخلي عن كلٍّ من جافاسكربت والتحريك الخاصّ بها. ما يحيّر المطوّرين هو الاستخدام الفعّال لـ CSS، فبينما يقومون بإدارة التفاعل بين العناصر من داخل CSS، يُجبرون أنفسهم أيضًا على جعل مشروعهم متوافقًا مع Internet Explorer 8 و 9، وأخيرًا، يتجنّبون التحريك الجاهز الذي لا يتوفر إلا عن طريق جافاسكربت. يهدف هذا المقال لدحض بعض الأساطير حول CSS وكشف جميع المشكلات الأساسية التي بالكاد يتحدث الناس عنها بسبب إعجابهم بـ CSS. يهدف المقال إلى رفع معرفتك ووعيك بفوائد استخدام جافاسكربت، حتى يمكنك بسهولة التخلص من المواقف التي تثير غضبك. لذا، دون مزيد من الإطالة دعونا نتناقش حول كل منهم بالتفصيل. 1. jQueryدعونا نبدأ بالأساسيات، يتم الربط بين جافاسكربت ومكتبة jQuery بشكل خاطئ . فالتحريك المُصمَّم بجافاسكربت سريع ومرن، بينما المُصمَّم بـ jQuery بطيء. السبب أنه -وبرغم مواصفات jQuery القوية- إلّا أنها لم تهدف بشكل رئيسي لتنفيذ التحريك. هناك العديد من الأسباب لدعم هذا: لا يمكن لمكتبة jQuery ببساطة أن تتوقف عن تحطيم التنسيق (layout thrashing) نظرًا لهيكلتها البرمجية التي تخدم عددًا من الأغراض غير التحريك. هذا بشكل عام يسبب تقطّعًا في المراحل الأولى من التحريك.الذاكرة التي تستهلكها jQuery دومًا تُحفّز جمع القمامة (Garbage Collection) مما يؤدي إلى تجمّد التحريك. ونظرًا لـ جمع القمامة، يمكن للمرء أن يواجه تقطّعًا أثناء التحريك.تم تصميم jQuery لتستخدم set_interval() وليس طلب إطار الحركة (Request Animation Frame - RAF). عندما لا يكون طلب إطار الحركة موجودًا فيمكن أن ينتج عن ذلك تحريكات بعدد إطارات منخفض (جودة ودقة الحركة تعتمد على عدد الإطارات التي تظهر في الثانية، العدد المثالي هو 60 إطار في الثانية).2. فقر التحكم بالتدوير وتحديد الموقعمن الميزات الأساسية الضرورية أثناء تنفيذ التحريك استخدام المُتحكّمات لـ: التحريك animation، التدوير rotation، وتحديد المواقع positioning. في CSS، تم تكديس جميع هذه الدوالّ في خاصية معروفة هي tranform. هذه الخاصية تُسبب مشاكل عند تحريك شيء ما بطريقة فريدة عن طريق عنصر مشترك. على سبيل المثال، إن أردت تحريك “التدوير” rotation و”التكبير” scaling بشكل منفصل، وباستخدام أزمنة مختلفة، فهذا مُمكن فقط عن طريق جافاسكربت ﻷنها تُمكّنك من استخدام حِيل متنوعة، وهذه غير مسموحة في CSS. هذه إحدى مساوئ CSS. هي جيدة من أجل مشاريع تتطلب تحريكاتٍ بسيطة وليس من أجل المشاريع التي تتطلب اندماج تصميمٍ بتحريكاتٍ كبيرة. 3. الأداء مع مكتبتيّ Velocity وGSAPVelocity وGSAP هما المكتبتان الرائدتان والأكثر شعبية في جافاسكربت. كلاهما يعمل مع jQuery أو بدونها. عندما يتم استخدام أيّ من هاتين المكتبتين جنبًا إلى جنب مع jQuery فلا يحدث أي تدهورأو تباطؤ في الأداء لأنهما تعملان بشكل منفصل عن تحريكات jQuery الأساسية. ويمكن أيضًا استخدام هاتين المكتبتين بسهولة عندما لا تكون مكتبة jQuery موجودة في الصفحة. وهذا يبين بوضوح أنه بدلًا من ربط جميع أنواع استدعاءات التحريك في عنصر jQuery مشترك يمكنك بشكل مباشر تمرير العنصر المراد إلى استدعاء الحركة كما هو مبين أدناه. /* Working without jQuery */ Velocity(element, { opacity: 0.4 }, 900); // Velocity TweenMax.to(element, 1, { opacity: 0.4 }); // GSAP في المثال السابق، يمكنك ملاحظة أن Velocity تستخدم نفس الصيغة حتى عندما لا يتم استخدام jQuery. قامت فقط بإزاحة جميع العناصر تجاه اليمين لترك مساحة للعناصر المستهدفة. بالمقابل، في GSAP تم استخدام تصميم كائني التوجه (عن طريق استدعاء كائن يمثّل صنف Class) جنبًا إلى جنب مع دالّة بسيطة ثابتة. بهذه الطريقة المستخدم يملك تحكم كامل بعملية الحركة. 4. معامل وحدة معالجة الرسوم (GPU)عندما تكون وحدة معالجة رسوم GPU مُحسّنة بشكل كامل، عندها ستكون عظيمة لأداء مهام متنوعة كالتعامل مع مصفوفات التحويل transform والشفافية opacity، لهذا السبب أول ما تفعله جميع المتصفحات المتطورة هو تفريغ هذه المهام من وحدة المعالجة المركزية CPU إلى وحدة معالجة الرسوم GPU. الهدف الأساسي هو فصل جميع العناصر المتحركة إلى طبقات خاصة بها في وحدة معالجة الرسوم ﻷنه فور انتهاء النظام من إنشاء طبقات وحدة معالجة الرسوم لا يُظهر النظام أي اهتمام بتحريك البكسلات وجمعهم معًا. لهذا لا يوجد حاجة بتاتًا لحساب كل بكسل بشكل مستمر. بدلًا من ذلك يمكن تحريك بكسل واحد فوق الآخر وتوفير كثير من الوقت. ملاحظة: لا حاجة لإعطاء كل عنصر طبقته الخاصة نظرًا لذاكرة الفيديو المحدودة في وحدة معالجة الرسوم. فإذا نفدت الذاكرة سيفسد كل شيء. من ناحية أخرى، إذا قمتَ بتعريف التحريك في CSS عندئذ ستكون مهمة المتصفح أن يحدد طبقة وحدة معالجة الرسوم لكل عنصر وسيحصل انقسام بسبب ذلك. مع ذلك، يمكنك عمل هذا الأمر عن طريق جافاسكربت أيضًا. كل ما تحتاجه هو تحديد التحويل transform مع خاصية 3D (تمامًا مثل translate3d() و matrix3d()) لجعل المُتصفح يعلم عن عملية إنشاء طبقات وحدة معالجة الرسوم للعنصر المستهدف. لذا، فمن الواضح أن وحدة معالجة الرسوم لا توفّر زيادة السرعة لـ CSS فقط بل لجافاسكربت أيضًا. 5. قوة تحريك جافاسكربتلدى جافاسكربت كل الإمكانيات للفوز بمقارنة الأداء مع CSS. جافاسكربت هي أسرع. لكن إلى أي حدّ يمكن أن تكون أسرع؟ بدايةً هي مرنة بما فيه الكفاية لإنشاء عرض تحريك ثلاثيّ الأبعاد 3D ملفت للنظر، الذي يمكن أن تراه عبر WebGL. وجافاسكربت سريعة بشكلٍ كافٍ لبناء دعاية وسائط متعددة، والتي كان من الممكن تطويرها باستخدام Flash أو After Effects. وبالتأكيد بناء عالم افتراضي باستخدام جافاسكربت بمساعدة Canvas. بقدر ما تكون مكتبات التحريك هي المعنية في هذا المقال، فإن الحديث الآن عن توثيق مكتبتيّ Transit و Velocity غير مبرر على الإطلاق. لمزيد من التوضيح لهذه النقطة، قمنا بطرح قائمة تحسينات يمكن فقط للتحريك المبنيّ بجافاسكربت أن يؤديها: مزامنة DOMالتخزين المؤقت للخصائص عبر سلسلة من الاستدعاءات، للتخفيف من استعلامات DOMالتخزين المؤقت لنسب تحويل الواحداتخلاصةنجد بوضوح كيف أن النقاط المذكورة أعلاه تسلط الضوء على براعة التحريك المبنيّ على جافاسكربت بالمقارنة مع المبنيّ على CSS. ولكن هل هذا يعني أن تحريك CSS “سيّء”؟ بالتأكيد لا. هو جيّد لأداء تحريك بسيط. لكن لمرونة وقدرات فريدة أعلى، يجب أن تأخذ جافاسكربت بعين الاعتبار. ترجمة -وبتصرفّ- للمقال CSS Vs JavaScript Myths Fall to Pieces