حوار مع فيليب حول Lightningjs ومستقبل واجهات ال OTT

حين تُذكر تطبيقات التلفاز وواجهات ال OTT، تبدأ الأسئلة الكبرى بالظهور:

• ما التقنية التي يمكنها الصمود أمام تنوع الأجهزة، وبطء معالجاتها، وصغر ذاكرتها؟

• هل ما زال الاعتماد على DOM ممكنا؟ أم أن الوقت حان للانتقال إلى محركات عرض جديدة كليا؟

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

مرحبا فليب، في رأيك، هل ال Lightningjs/Blits هي الأفضل لمشاريع التلفاز وال OTT؟

لدي خبرة تمتد إلى 12 سنة في بناء تطبيقات التلفاز و ال OTT باستخدام أطر مختلفة، في السابق كانت تعتمد على ال DOM سواء عبر أطر مخصصة أو باستخدام ReactJS، لكن كان من المستحيل تقديم تجربة غنية وسلسة.

لقد جرّبنا مكتبات مثل PixiJS، لكنها كانت مصممة للألعاب بشكل أكبر، وكانت تفتقر إلى مميزات مهمة لتطبيقات التلفاز مثل إدارة التركيز Focus Management أو التعامل مع عدد كبير من الصور، وهي أشياء تضطر إلى بنائها بنفسك ..

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

ما مدى قابلية دمج إطار عمل أو مكتبة أخرى مع lightningjs؟

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

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

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

ما هي أفضل الطرق لمراقبة الأداء FPS، الذاكرة، ال GPU وغيرها أثناء التطوير؟

القاعدة الذهبية مع Lightningjs:

• أنشئ عناصر أقل في الصفحات

• اجعل الشجرة Element Parent قليلة و flat قدر الإمكان .. 

عندما ذكرتَ أن من المهم keep the tree flat لتحسين الأداء في تطبيقات التلفاز،

هل يمكنك توضيح المقصود بذلك عمليا؟ كيف يمكن للمطور تطبيق هذا المفهوم داخل المكونات لتقليل الحمل على المعالج والذاكرة؟

فيليب:

مثال لكود سيء:

import { Lightning } from "@Lightningjs/sdk";
export class DeepTreeExample extends Lightning.Component {
  static _template() {
    return {
      Wrapper: {
        x: 100, y: 100,
        Label: {
          text: { text: "Movies", fontSize: 32 },
          Rail: {
            x: 0, y: 60,
            Row: {
              flex: { direction: 'row' },
              Tile1: { rect: true, w: 150, h: 220, color: 0xff4444ff },
              Tile2: { rect: true, w: 150, h: 220, x: 160, color: 0xff44ff44 },
            }
          }
        }
      }
    };
  }
}

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

import { Lightning } from "@Lightningjs/sdk";
export class FlatTreeExample extends Lightning.Component {
  static _template() {
    return {
      Title: { x: 100, y: 100, text: { text: "Movies", fontSize: 32 } },
      Tile1: { x: 100, y: 160, rect: true, w: 150, h: 220, color: 0xff4444ff },
      Tile2: { x: 260, y: 160, rect: true, w: 150, h: 220, color: 0xff44ff44 },
    };
  }
}

هذا يقلل الحمل على ال GPU ويزيد من سرعة التنقل في واجهات التلفاز بنسبة قد تصل إلى 30–40% في بعض الأجهزة القديمة.

هل أدوات Chrome DevTools كافية أم هناك أدوات خاصة لتطبيقات التلفاز؟

نعم، يمكن استخدم Chrome DevTools لقياس:

• استهلاك الذاكرة JS heap usage

• زمن تنفيذ الجافاسكربت

• استهلاك الشبكة

• كما أن كثيرا من أجهزة التلفاز تتيح Remote DevTools لمراقبة الأداء مباشرة على الجهاز.

على مستوى Lightningjs نفسه:

• نستخدم مكتبة stats.js لعرض بعض المؤشرات مثل معدل الإطارات FPS، ومستوى ضغط القوام (texture pressure)، وعدد العناصر النشطة

• لدينا أيضا أداة داخلية تسمح لنا بتتبع إزالة العناصر elements removal، لمساعدتنا في اكتشاف المشاكل التي تنتج عن تحديثات تفاعلية reactive updates تتسبب بإعادة إنشاء العناصر رغم أنها غير مرئية.

أما أدوات WebGL debugging فوجدنا أنها غير مفيدة كثيرا في حالتنا، عدد أوامر الرسم  Draw Calls معتدل، ولا نستخدم RTT بكثافة، لذا فإن مراقبة الذاكرة كافية كمؤشر.

حسنا، وضحت الصورة، كيف تنصح بهيكلة المكوّنات والصفحات داخل مشروع Lightningjs ليكون قابلا للتوسع؟

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

• الاعتماد على التركيب composition وفصل المسؤوليات separation of concerns 

• جعل الشاشات views تُحمّل بشكل كسول lazy loading 

• لا تقم برسم كل ال Rails مرة واحدة (مثل 40 صفا في الصفحة الرئيسية)

• استخدم Virtualization لعناصر ال tiles حتى تُعرض فقط المرئية منها

• واجعل كل Rail يُحمّل بياناته تدريجيا أثناء التمرير scrolling 

ما المقصود ب rails of tiles، وكيف يؤثر على الأداء وطريقة بناء الواجهة في Lightningjs؟

الفكرة بسيطة: لدينا عدة Rails تمثل أقسام الصفحة مثل الأفلام، المسلسلات، أوالأطفال، وكل Rail يحتوي على مجموعة من Tiles تُعرض أفقيا ويمكن التنقل بينها بواسطة جهاز التحكم Remote.

التحدي الحقيقي ليس في التصميم نفسه، بل في كيفية التعامل مع الأداء performance، إذ يجب أن تكون الـ Rails محملة بشكل كسول lazy  بحيث لا تُنشأ جميعها دفعة واحدة، وأن تكون ال Tiles مفعّلة بال  virtualization لتُعرض فقط عندما تكون مرئية على الشاشة، مما يمنع التطبيق من التجمّد عند تحميل الصفحة الرئيسية.

ما أفضل طريقة للتعامل مع البيانات Data Flow داخل مكونات Lightningjs؟ وكيف نتجنب مشاكل الأداء أو الذاكرة خاصة في جلب قوائم كثيرة من ال API؟

• نحاول جلب البيانات محليا وبشكل كسول lazy داخل مكونات ال CMS أو المجال domain components

• نجعل الطلبات قابلة للإلغاء cancellable في حال تم إلغاء تحميل المكون unmounted ..

• يتم تحرير البيانات عند التخلص من المكون disposed

• لا نستخدم نظام تخزين مركزي cache، فهو الجزء الأكثر خطورة.  // تعليق من المحاور (لم أفهم السبب، وفاتني أن أسأل عن ذلك)

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

ال Lightningjs لا يدعم RTL بشكل افتراضي، لكننا عملنا على إضافة دعم اللغة العربية من خلال مساهمات متنوعة في Lightningjs 2، وهي موجودة حاليا في حزمة تجريبية beta package. من الممكن أن يقوم فريق Lightning الرسمي بدمجها لاحقا، أو قد أقوم أنا بذلك عندما نبدأ عملية الانتقال إلى المحرك الجديد ..

كيف يرى فيليب مستقبل OOT عموما؟ وهل يعتقد أن Lightningjs وBlits سيبقيان في الصدارة أمام تسارع تطور أطر الويب الحديثة؟

ما زال أمامنا الكثير لنفعله في هذا المجال. Lightningjs لم تُصمم لتكون مثل React أو Vue، بل لتعمل بثبات على أجهزة عمرها عشر سنوات، وبذاكرة محدودة، وبدون متصفح حديث.

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

قبل أن نختم، لدي سؤال فضولي، ما هي التقنيات الأخرى التي تستخدم في بناء هذه التطبيقات؟

نعم، هناك React TV و Enact وTOAST، بل وحتى محاولات لتكييف React و WebGL لتقديم أداء مشابه ل Lightningjs،  لكنها كلها تبقى مبنية على ال DOM، وهو ما يجعلها محدودة عندما نصل إلى تلفزيونات بذاكرة 512 ميغابايت أو معالجات ضعيفة، ال Lightningjs تم تصميمها من البداية لتعمل في هذه البيئات المنخفضة الأداء، حيث لا يمكن الاعتماد على DOM أو CSS ..

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

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

---
شكرا فيليب ..
شكرا نعيم ..