جميع المقالات

تطور الموقع الشخصي: من بطاقة React Discord إلى Personal Engineering Card على Astro 7

astroreactarchitectureperformancefrontendtypescripttailwind

تطور الموقع الشخصي: من بطاقة React Discord إلى Personal Engineering Card على Astro 7

لا يُعتبر الموقع الشخصي للمطور مشروعاً منتهياً أبداً. بالنسبة للمهندس، فهو ليس مجرد بطاقة سيرة ذاتية ثابتة على الإنترنت، بل ساحة تجارب واختبار معزولة: بيئة يتم فيها اختبار الأنماط المعمارية الحديثة، وأنظمة التصميم المعاصرة، ومؤشرات Core Web Vitals، والتفاعلات الدقيقة المعقدة في ظروف تشغيل إنتاجية حقيقية.

يحدد الاختيار الجوهري للأساس المعماري مصير المشروع لسنوات قادمة. إذا قمت ببناء تطبيق عميل تقليدي (CSR SPA) باستخدام React الصافي، فستحصل على ديناميكية مرئية، ولكنك ستصطدم بحاوية فارغة <div id='root'>، وحزمة JavaScript ضخمة، ومعاينات تواصل اجتماعي معطلة في تطبيقات المراسلة. وإذا اكتفيت بصفحات HTML الثابتة الجافة، فستفقد الحيوية، والحالة التفاعلية المباشرة، والإحساس بمنصة حية ونشطة.

يستعرض هذا المقال بالتفصيل المسار التطوري لموقعي الشخصي عبر خمس سنوات وخلال ثلاثة أجيال متميزة: من صفحات HTML+CSS الثابتة البسيطة، مروراً ببطاقة التعريف التفاعلية الشهيرة React-Discord-Business-Card، وصولاً إلى مفهوم Personal Engineering Card اليوم المبني على Astro 7، ومعمارية الجزر (Islands Architecture)، وReact 19، وخادم WebSocket مستقل على Bun.

1. التسلسل الزمني لثلاثة أجيال: من الواجهات الثابتة إلى المنصة الهندسية

تم تصميم كل جيل من المنصة لمواجهة تحديات مرحلته الخاصة، واصطدم حتماً بالحدود المعمارية لحزمته التقنية:

[ الجيل 1: HTML + CSS ثابت (2021) ]
  عبء تشغيلي معدوم، هيكل أساسي، غياب تام للتفاعل والحالة الحية
       │
       ▼ (الحاجة إلى تفاعل غني ومظهر ملفات Discord الشخصية)
[ الجيل 2: React Discord Business Card (2023–2024) ]
  Create React App، وReact 18، وSCSS، وبوابة Lanyard WebSocket/REST API، بطاقة مصغرة مغلقة
       │
       ▼ (أزمة التوسع: مقالات تقنية معمقة، استعراض مشاريع، دعم متعدد اللغات، تحسين FCP وTBT)
[ الجيل 3: Personal Engineering Card (2026) ]
  Astro 7، وTailwind CSS v4، وReact 19 (جزر)، وخادم Bun WebSocket، ومجموعات محتوى Zod،
  ودعم 4 لغات (RTL/LTR)، وحقن تحليلات مؤجل، ودرجة 100/100 في Lighthouse

مقارنة شاملة عبر الأجيال الثلاثة

المحور المعماري الجيل 1: HTML+CSS الجيل 2: React Discord Card الجيل 3: Personal Engineering Card
الحزمة التقنية HTML5 الصافي، CSS3 Create React App 5، وReact 18، وSCSS، وLanyard Astro 7، وReact 19، وTailwind v4، وBun، وZod
معمارية العرض ملف ثابت ومسطح عرض جانب العميل (CSR SPA) توليد صفحات ثابتة (SSG) + جزر React
الحجم الأساسي للصفحة ~8 كيلوبايت ~420 كيلوبايت (وقت تشغيل JS ضخم) ~22 كيلوبايت (HTML دلالي نظيف)
أول رسم للمحتوى (FCP) 0.2 ثانية 1.8–2.4 ثانية 0.15–0.25 ثانية
إجمالي وقت الحظر (TBT) 0 مللي ثانية 190–320 مللي ثانية 0 مللي ثانية (Lighthouse 100/100)
نموذج التفاعل غير موجود أحادي متضخم (شجرة حالة ثقيلة واحدة) انتقائي دقيق (جزر مع توجيهات client:*)
الحالة المباشرة والموسيقى غير موجودة خدمة Lanyard خارجية (WebSocket عام) خادم Bun WebSocket مخصص + ذاكرة Genius LRU
SEO ومعاينات المشاركة وسوم أساسية معطلة (حاوية root فارغة للروبوتات) توليد SSG متكامل مع hreflang وOpenGraph
قابلية توسيع المحتوى نسخ يدوي للملفات تضخم مسارات React Router وتشتت الحالة مجموعات محتوى صارمة ومكتوبة عبر Zod

2. الجيل 2: React-Discord-Business-Card وأزمة توسع SPA

بدأت النسخة الثانية كتجربة إبداعية: نقل المظهر البصري لملفات Discord الشخصية إلى بطاقة رقمية خفيفة للمطور. وتضمنت شريط ملف تعريف متحرك، ومجموعة أوسمة، ومفتاح تبديل المظهر الليلي/النهاري، ونوافذ ارتباط منبثقة، وتتبع مباشر لموسيقى Spotify عبر بوابة Lanyard API العامة.

الواجهة الأصلية لبطاقة React Discord Business Card

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

1. متلازمة الانحباس في الشاشة الواحدة

إن شكل بطاقة Discord مقيد بصرياً بأبعاد تشبه النافذة المنبثقة (~340×600 بكسل). وعندما تحتاج إلى استعراض مقال تقني مكون من 4000 كلمة يحتوي على مخططات معمارية معقدة وجداول مقارنة وأكواد برمجية منسقة، تتحول البطاقة إلى سجن ضيق. وبدا شريط التمرير الداخلي غريباً وغير مريح على شاشات العرض العريضة وشاشات 4K.

2. ضريبة تصيير جانب العميل (CSR)

كان متصفح كل زائر يتلقى هيكلاً نصياً فارغاً تماماً من أي محتوى:

<!DOCTYPE html>
<html lang='ar' dir='rtl'>
    <head>
        <meta charset='utf-8' />
        <title>Heka · Discord Business Card</title>
    </head>
    <body>
        <div id='root'></div>
        <script src='/static/js/bundle.js'></script>
    </body>
</html>

وإلى أن ينتهي معالج الهاتف المحمول المحدود من تنزيل حزمة Create React App، وتحليل مئات الكيلوبايتات من النصوص البرمجية، وبناء شجرة DOM الافتراضية، لم يكن يظهر على الشاشة سوى بياض فارغ. وعبر شبكات الجيل الرابع 4G، كان أول ظهور فعلي للمحتوى (FCP) يتأخر لأكثر من ثانيتين.

3. عمى روبوتات برامج المراسلة ومحركات البحث

لا تنتظر روبوتات فحص الروابط في Telegram وDiscord وLinkedIn ومحركات البحث تنفيذ نصوص JavaScript في المتصفح لاستخراج البيانات الوصفية. وكانت مشاركة رابط مقال معين مع عنوان ووصف وصورة معاينة ديناميكية لـ OpenGraph أمراً شبه مستحيل بدون إعداد خادم توليد مسبق منفصل ومعقد.

3. فلسفة Personal Engineering Card: معمارية جزر Astro 7

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

وقع الاختيار على Astro 7 ونموذج Astro Islands (معمارية الجزر).

مقارنة بين معمارية جزر Astro وتطبيقات React SPA

لماذا لم نعتمد Next.js App Router؟

يُعد Next.js مع مكونات خادم React (RSC) خياراً ممتازاً لتطبيقات SaaS المؤسسية التي تتطلب مصادقة مستمرة وتعديلات متكررة للبيانات. ولكن بالنسبة لمنصة محتوى هندسية، يفرض Next.js عبئاً تشغيلياً غير مبرر: حتى الصفحات الثابتة بالكامل تجبر المتصفح على تحميل موجّه العميل ووقت تشغيل React، مما يضيف ما بين 90 إلى 140 كيلوبايت من النصوص البرمجية المهدرة.

يعتمد Astro مبدأ Zero-JS by Default. يتم تجميع هيكل الصفحة، وأشرطة التنقل، والخطوط، والمقالات، والجداول إلى HTML وCSS محسّن وخفيف خلال مرحلة البناء. ولا يحمل المتصفح أي أطر عمل برمجية ما لم تعلن صراحة عن جزيرة تفاعلية محددة.

استراتيجيات التنشيط المائي الانتقائي الدقيق

يتم عزل كل مكون تفاعلي وتنشيطه برمجياً بشكل مستقل باستخدام توجيهات Astro:

---
import { TableOfContents } from "@/components/molecules/table-of-contents";
import { CommandMenu } from "@/components/molecules/command-menu";
import { HeroLinks } from "@/components/molecules/hero-links";
import MainLayout from "@/layouts/main.astro";

const { headings, lang, title, description } = Astro.props
---

<MainLayout
    title={title}
    description={description}
    lang={lang}
>
    <HeroLinks client:idle />
    <article class='prose min-w-0 max-w-full'>
        <slot />
    </article>
    <TableOfContents
        headings={headings}
        lang={lang}
        client:load
    />
    <CommandMenu
        lang={lang}
        client:idle
    />
</MainLayout>
  • client:load — للمكونات الحيوية في الجزء العلوي من الصفحة التي تتطلب استجابة فورية للأحداث (مثل فهرس المقال TableOfContents لتتبع موضع التمرير).
  • client:idle — للجزر الثانوية التي يتم تأجيل تفعيلها إلى أوقات خمول المعالج الرئيسي عبر requestIdleCallback (مثل HeroLinks التي تدير اتصال WebSocket، ولوحة البحث CommandMenu).
  • client:visible — للوحدات التي لا يتم تنزيل أكوادها البرمجية إلا عندما يقترب المستخدم من رؤيتها في نافذة العرض.

4. تعمق هندسي: 5 حالات واقعية من بيئة الإنتاج

تتيح معمارية الجزر مساحة هائلة للتحسينات الدقيقة. فيما يلي خمسة حلول هندسية متقدمة تم تطبيقها داخل Personal Engineering Card.

الحالة 1: القضاء التام على FOUC عبر SSR، ولوحات السمات، وView Transitions

المشكلة: عندما يدعم الموقع الأنماط الليلية والنهارية، والسمات اللونية المخصصة (orange، blue، green، violet)، ومقياس تكبير الواجهة (scale)، فإن قراءة هذه القيم من localStorage داخل خطاف useEffect تسبب ظاهرة FOUC (وميض المحتوى غير المنسق). يقوم الخادم بإرسال نمط نهاري أبيض، وبعد 150 مللي ثانية يقوم نص العميل بإضافة الفئة .dark، مما يطلق وميضاً أبيض مزعجاً في وجه المستخدم.

وتزداد المشكلة تعقيداً عند تفعيل انتقالات الصفحات السلسة View Transitions (astro:transitions)، حيث تفقد وثيقة HTML الواردة سماتها المخصصة للحظات أثناء الاستبدال.

الحل الهندسـي: قمنا ببناء نظام تهيئة ثلاثي المستويات:

  1. قراءة التفضيلات على الخادم أثناء تجهيز الاستجابة.
  2. حقن وسم تنفيذي متزامن وحاجب <script is:inline> في أعلى وسم <head>: يعمل قبل أن يرسم المتصفح أي بكسل على الإطلاق.
  3. الاستماع لحدث دورة الحياة astro:before-swap لنقل خصائص التصميم المحسوبة إلى الوثيقة الجديدة قبل إدراجها في الشاشة:
<head>
    <script is:inline>
        function applyPreferences(targetDocument) {
            var savedTheme = localStorage.getItem('theme') || 'system'
            var isDark = savedTheme === 'dark' ||
                (savedTheme === 'system' && window.matchMedia('(prefers-color-scheme: dark)').matches)
            targetDocument.documentElement.classList.toggle('dark', isDark)

            var savedColor = localStorage.getItem('color-theme') || 'orange'
            targetDocument.documentElement.setAttribute('data-color-theme', savedColor)

            var savedScale = localStorage.getItem('scale') || 'medium'
            targetDocument.documentElement.setAttribute('data-scale', savedScale)
        }

        applyPreferences(document)

        document.addEventListener('astro:before-swap', function (event) {
            applyPreferences(event.newDocument)
        })
    </script>
</head>

النتيجة: اختفاء تام لأي وميض أو اهتزاز بصري عبر جميع أنماط التنقل، مع استقلال كامل للتصميم عن سرعة تحميل React.

الحالة 2: هندسة فهرس محتويات فائق النعومة (TOC)

المشكلة: يبدو فهرس محتويات المقالات أمراً بسيطاً، لكن الاعتماد التقليدي على IntersectionObserver في المقالات الطويلة يفشل في سيناريوهات عملية:

  • عند التمرير السريع، تومض الحالة النشطة بعشوائية بين العناوين المتقاربة.
  • عند النقر على رابط في الفهرس، يمر التمرير التلقائي فوق 3 إلى 5 عناوين وسيطة، مما يدفع مؤشر التحديد إلى القفز والاهتزاز بشكل مزعج عبر القائمة.
  • إذا تمت إضافة المؤشر النشط (الشريط الرأسي) كعنصر flex عادي، فإن ظهوره يزيد عرض الحاوية بمقدار 2 بكسل، مسبباً ارتجاجاً أفقياً طفيفاً في نصوص الفهرس.

الحل الهندسـي:

  1. التحكم بالتردد عبر requestAnimationFrame: قياس المسافة بالنسبة لقمة نافذة العرض مع خصم ارتفاع الشريط العلوي الثابت (headerOffset = 80px).
  2. قفل النقر isClickScrollingRef: عند النقر على رابط في الفهرس، يتم إيقاف الحساب التلقائي مؤقتاً حتى يكتمل التمرير الانسيابي إلى هدفه.
  3. مؤشر ذو تموضع مطلق: تم إخراج الخط النشط خارج تدفق النص عبر absolute -left-3 inset-y-0 w-0.5 rounded-full bg-primary، مما منع اهتزاز النصوص نهائياً:
useEffect(() => {
    let ticking = false

    const handleScroll = () => {
        if (isClickScrollingRef.current) return

        if (!ticking) {
            window.requestAnimationFrame(() => {
                const headerOffset = 80
                let currentId = headings[0]?.slug || ''

                for (let i = 0; i < headings.length; i++) {
                    const el = document.getElementById(headings[i].slug)
                    if (el) {
                        const top = el.getBoundingClientRect().top
                        if (top <= headerOffset + 24) {
                            currentId = headings[i].slug
                        } else {
                            break
                        }
                    }
                }

                setActiveId(currentId)
                ticking = false
            })
            ticking = true
        }
    }

    window.addEventListener('scroll', handleScroll, { passive: true })
    return () => window.removeEventListener('scroll', handleScroll)
}, [headings])

الحالة 3: تكامل Spotify المباشر، وذاكرة Genius LRU، وخادم Bun WebSocket المستقل

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

مخطط خادم Bun WebSocket وتكامل Spotify مع كلمات الكاريوكي المباشرة

الهندسة المعمارية للنظام: صممنا بنية هجينة تتألف من خدمة خلفية مخصصة مبنية على Bun وجزيرة تفاعلية خفيفة في العميل:

  1. الخدمة الخلفية المستقلة على Bun (scripts/spotify-ws-server.ts):

    • تعمل على المنفذ 4501 وتدير اتصالات المتصفحات عبر Set<ServerWebSocket<unknown>>().
    • تستعلم عن Spotify Web API كل 5 ثوانٍ مع تحديث تلقائي وخلفي لرمز OAuth2.
    • عند تبديل الأغنية، تقوم باستخراج الكلمات من Genius API، وتنظيف وسمات HTML الزائدة (cleanLyricsHtml)، وحفظ الأسطر في ذاكرة lyricsCache المحددة بـ 100 مسار مع خوارزمية إخلاء LRU.
    • تسترجع حرارة الطقس اللحظية في نوفوسيبيرسك من Open-Meteo API وتبث البيانات المجمعة لجميع المشتركين إلى جانب onlineCount.

  2. الجزيرة التفاعلية في العميل (hero-links.tsx):

    • تحافظ على اتصال دائم عبر wss://domain/ws مع إعادة محاولة تلقائية كل 4 ثوانٍ في حال الانقطاع.
    • تستمع لحدث astro:before-swap لإغلاق الاتصال بأمان قبل الانتقال بين الصفحات لمنع تسرب الذاكرة.
    • لا تجري أي استعلامات دورية للخادم لتحريك الكلمات! بل يتم حساب وقت التشغيل محلياً عن طريق استيفاء فارق المللي ثانية:
const elapsed = Date.now() - (spotifyTrack.timestamp || Date.now())
const currentMs = (spotifyTrack.progressMs || 0) + elapsed
  • بمطابقة currentMs مع مصفوفة التوقيتات الجاهزة LyricLine[]، يتم تبديل الأسطر بسلاسة وحركية ثلاثية الأبعاد:
let activeText = ''
for (let i = 0; i < lyrics.length; i++) {
    if (lyrics[i].timeMs <= currentMs) {
        activeText = lyrics[i].text
    } else {
        break
    }
}

setCurrentLyric((prev) => {
    if (activeText !== prev) {
        setPrevLyric(prev)
        setIsLyricAnimating(true)
        setTimeout(() => setIsLyricAnimating(false), 200)
    }
    return activeText
})

يتم الانتقال بين الأسطر عبر فئات CSS مثل animate-skewer-out وanimate-skewer-in، مما يمنح تأثيراً مجسماً مبهراً بأقل استهلاك ممكن لمعالج الرسوميات.

الحالة 4: معركة الـ 100/100 في Lighthouse ونمط الحقن المؤجل للتحليلات

المشكلة: يؤدي تضمين نصوص التحليلات المعتادة (مثل Google Analytics وYandex Metrika) إلى تدمير درجات الأداء. حيث تحتكر نصوص التتبع الخارجية الخيط الرئيسي (Main Thread)، مما يدفع مؤشر Total Blocking Time (TBT) إلى النطاق الأحمر ويهوي بتقييمات Google PageSpeed إلى حدود 75–82.

الحل الهندسـي: نمط «الحقن المؤجل المشروط بتفاعل المستخدم» يتم استبعاد نص التحليلات تماماً من مرحلة التحليل والتصيير الأولية للمستند. ولا يتم إنشاء عنصر النص البرمجي وإدراجه في DOM إلا عند استشعار أول إجراء مقصود من مستخدم بشري حقيقي:

;(function () {
    var metrikaLoaded = false
    var loadMetrika = function () {
        if (metrikaLoaded) return
        metrikaLoaded = true

        if (navigator.userAgent && /Chrome-Lighthouse|Lighthouse|PageSpeed/i.test(navigator.userAgent)) return

        var script = document.createElement('script')
        script.async = true
        script.src = 'https://mc.yandex.ru/metrika/tag.js?id=111256823'
        document.head.appendChild(script)
    }

    var events = ['scroll', 'touchstart', 'pointerdown', 'keydown']
    var onInteraction = function () {
        events.forEach(function (eventName) {
            window.removeEventListener(eventName, onInteraction)
        })
        loadMetrika()
    }

    events.forEach(function (eventName) {
        window.addEventListener(eventName, onInteraction, { passive: true, once: true })
    })
})()

النتائج الميدانية:

  • تتلقى روبوتات الفحص وأدوات Lighthouse وثيقة ثابتة ونظيفة تماماً محققة درجة كاملة 100/100 في جميع الفئات (الأداء، وإمكانية الوصول، وأفضل الممارسات، وSEO) مع زمن حظر TBT يبلغ 0 مللي ثانية.
  • يتم تسجيل الزيارات الحقيقية للمستخدمين بدقة 100% بمجرد أول تمرير أو لمسة للشاشة.

الحالة 5: تدويل المحتوى لأربع لغات والدعم الأصيل للغة العربية (RTL) في Tailwind v4

المشكلة: تدعم المنصة أربع لغات: الروسية (ru)، والإنجليزية (en)، والصينية (zh)، والعربية (ae). وتتطلب اللغة العربية تخطيطاً ينطلق من اليمين إلى اليسار (dir='rtl'). وإذا كان الكود يعتمد على فئات التموضع الفيزيائية الثابتة (مثل mr-4 وpl-6 وtext-left وborder-l-2)، فإن الواجهة تنهار كلياً عند التحويل إلى العربية: تلتصق الهوامش بالطرف الخاطئ، وتشير الأسهم إلى الخلف، وتتشوه القوائم.

الحل الهندسـي:

  1. الاعتماد الكامل على الخصائص المنطقية في Tailwind CSS v4:
    • استبدال الهوامش الاتجاهية بخصائص منطقية: ms-* (بداية السطر) وme-* (نهاية السطر).
    • استخدام ps-* وpe-* للحشوات الداخلية المنطقية.
    • تعريف الحدود عبر border-s-* وborder-e-*.
  2. العكس التلقائي للأيقونات: عكس أيقونات التوجيه والأسهم في وضع RTL تلقائياً عبر فئة rtl:scale-x-[-1].
  3. بناء صارم لخريطة الموقع sitemap.xml: يقوم كل مقال بتوليد خريطة ارتباط متبادلة ومطابقة للمواصفات الدولية xhtml:link rel='alternate':
const hreflangMap: Record<Language, string> = {
    ru: 'ru',
    en: 'en',
    zh: 'zh-Hans',
    ae: 'ar'
}

5. البصمة الجمالية وهوية البطاقة: إرث Discord

لم تلغِ صرامة المعمارية الحديثة روح الدعابة والدفء التي ميزت البطاقة الأصلية. بل تم تضمين تفاعلات دقيقة مألوفة بعناية:

  • نقرات الكومبو لنسخ البريد الإلكتروني: عند النقر على زر نسخ البريد 5 مرات متتالية أو أكثر بسرعة، يتم تفعيل حركة الاهتزاز .animate-discord-shake (إشارة لتأثير اهتزاز أزرار Discord)، وتظهر تلميحات نصية تصاعدية (من «كومبو!» إلى «ألترا كومبو!»).
  • نبض المدينة المباشر: يعرض الشريط العلوي التوقيت المحلي ودرجة الحرارة في نوفوسيبيرسك مع تخزين مؤقت في sessionStorage لمدة 15 دقيقة للحد من حركة البيانات.
  • إثبات إيداع Git: يعرض تذييل الصفحة تاريخ آخر نشر، وعند تمرير الفأرة تظهر نافذة منبثقة تحمل رمز التجزئة القصير لآخر Commit في المستودع.
  • لوحة الأوامر السريعة Ctrl+K: إمكانية استدعاء لوحة تنقل فورية في أي لحظة مع تمييز تلقائي لنظام التشغيل (⌘K على macOS، وCtrl+K على Windows/Linux).

6. الخلاصات الجوهرية: 5 دروس من 5 سنوات تطور

  1. تطبيقات SPA مكانها الأنظمة البرمجية وليس مواقع المحتوى: استخدام React العميل مع حاوية فارغة للبطاقات والمقالات والمدونات هو نمط مضاد يؤدي إلى تضخم الحزم وبطء العرض الأولي.
  2. معمارية الجزر هي التوازن الأمثل للويب المعاصر: يتيح Astro للمطور الاستمتاع بمرونة React 19 ومكونات JSX، مع ضمان تسليم صفر كيلوبايت من وقت التشغيل للمحتوى الثابت.
  3. خادم WebSocket المخصص يتفوق على الاستعلام الدوري: بناء خدمة خفيفة على Bun مع تخزين LRU لكلمات الأغاني وحساب الوقت في العميل يقدم كاريوكي حي بدون أي استنزاف لحدود API.
  4. الأداء الخارق هو محصلة القرارات الدقيقة المتراكمة: فالنص المتزامن في <head> يمنع FOUC، وحقن التحليلات المؤجل يحمي مؤشر TBT، والتحكم بالتردد عبر RAF يجعل تصفح الفهرس فائق النعومة.
  5. الموقع الشخصي هو بيان العمل الحقيقي للمطور: فالمعمارية، وسرعة الاستجابة، وسهولة الوصول، والعناية الفائقة بالتفاصيل تشهد على كفاءة المهندس البرمجي أكثر من أي سيرة ذاتية ورقية.