نصائح المرشدين عن Frontend Development

دخل معايا مهندس برمجة و hardware ..
عامل قناة يوتيوب بيشرح فيها حاجات في مجال الـ hardware ..

الطلاب عايزين يجربوا وراه طبعا .. فعايزين يشتروا الادوات ومش عارفين يشتروها منين ..

فهو قرر يعمل موقع ليهم يبيع فيه الادوات دي .. بس مش عايز يصعب الموضوع ويعمل database و backend و server apps وكلام من دا .. هو عايز حاجه functional ..

• روحنا جبنا صورة UI عجبته لمتجر من pinterest ..
• وفتحنا claude code على الجهاز .. وكتبنا ليه prompt منظم ومرتب .. انه يبني الموقع بنظام معين فرونت بس ..
• وخلينا الداتا تكون ملف مستقل علشان يقدر يعدل عليه بسهولة في اي وقت ..
• وخلينا الناس تضيف منتجات للـ cart بسهولة وتتحفظ ف الـ local storage عندهم ..
• ووقت الـ checkout عملنا button بيفتح whatsapp link في message منظمه بالـ order .. العميل يبعتها علطول ..
• ورفعنا الكلام الجميل دا على github ..
• وعملنا ليه deploy على vercel ..

اهو http://ghannam-pearl.vercel.app

علمته ازاي يعمل حاجه functional تؤدي المهمة اللي هو عايزها في 10 دقايق ..

وقالي بكل وضوح .. لو لقيت بيجيلي منه orders كويسه وبدأ يكسب .. وقتها هبدأ احوله لـ product حقيقي بالـ backend والـ database بتاعته ..

مش لازم يبدأ بحاجه سوبر واو .. هو مستعجل .. ومش معاه ميزانية .. وعايز يشوف الموضوع هيجيب همه ولا لا الأول .. فكان دا الحل اللي وصلنا ليه معاه ..

ايه رأيك .. تتفق مع الـ approuch دا ولا لا ؟

سنة 1865، الاقتصادي William Stanley Jevons لاحظ حاجة مثيرة للاهتمام.

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

الفكرة دي اتعرفت بعد كده باسم Jevons Paradox.

لما تكلفة حاجة بتقل، مش شرط نستخدم منها أقل. أحيانًا بنبدأ نستخدمها في حاجات ماكنّاش نقدر نبرر تكلفتها قبل كده.

بص على اللي حصل مع Cloud.

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

ودلوقتي، إحنا قدام تحول مشابه محتمل في صناعة الـ Software.

AI بيقلل تكلفة تنفيذ أجزاء كبيرة من عملية التطوير، وده ممكن يخلي شركات أكتر تجرب أفكار جديدة، وتبني أدوات داخلية، وتوسّع منتجاتها.

بس كل ما قدرتك على إنتاج الكود تزيد، بيظهر سؤال أهم:

مين هيحدد إحنا محتاجين نبني إيه أصلًا؟ ومين هيتأكد إن اللي بنبنيه صح، قابل للصيانة، ويستحمل التوسع؟

المستقبل مش مجرد إنك تعرف تكتب كود أسرع. المستقبل إنك تفهم إزاي تبني Software صح.

وده جزء أساسي من اللي بحاول أساعد الناس تفهمه في المينتورشب.

مش مجرد إنك تتعلم React أو Next.js أكتر، لكن إنك تطور طريقة تفكيرك، وتفهم القرارات الهندسية اللي ورا الكود، وتعرف تتعامل مع المشاكل اللي مفيش Tutorial جاهز يحلها.

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

وده مش معناه إن عندي كل الإجابات، لكن معناه إن الفهم الصح وطريقة التفكير بيفرقوا فعلًا.

السؤال مش بس: هل اAI هيكتب كود أكتر؟

السؤال: هل أنت بتبني خبرتك عشان تكتب الكود، ولا عشان تفهم الـ Software اللي بتبنيه؟

إزاي صفحة Next توصل فورا وجواها بيانات خاصة بالمستخدم؟

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

الـ Partial Prerendering بتدّيك الاتنين في صفحة واحدة.

وقت الـ Build، Next بتعدّي على شجرة الـ Components وتقرر مصير كل حتة:
\

• حاجة متخزنة بـ use cache، أو حاجة ثابتة (imports، قراءة ملف محلي، حسابات بحتة): بتدخل الـ Static Shell.\
• حاجة جوه Suspense: الـ Fallback بس هو اللي بيدخل الـ Shell، والمحتوى الحقيقي بييجي وقت الطلب.
  
  الـ Shell ده HTML بيتخدم من الـ CDN مباشرة، ومعاه RSC Payload للتنقل جوه الموقع. يعني أول محتوى بيوصل من غير ما السيرفر الأصلي يتحرك.
  
  والتفصيلة اللي بتفرق: كل ما كانت الحاجة اللي بتستنى الـ Request أعمق في الشجرة، كل ما الـ Shell بتاعك أكبر.
  
  مثال: لو الـ Layout قرا الـ params في أول سطر، الـ Layout كله بقى بيستنى الـ Request ومش هيدخل الـ Shell. لو نقلت القراءة جوه Component صغير ملفوف في Suspense، الباقي كله بيدخل الـ Shell.
  
  ولو الـ params مجهولة وقت الـ Build، بيطلع App Shell مشترك، وبعد أول زيارة بيتحدث للنسخة الكاملة (ISR).
  
  سؤال: Component بتاعك بيقرا الـ Request فين في الشجرة؟

ليه بنحس إن تطبيقات زي Stripe و Apple و Linear منتجات بملايين الدولارات، بينما أغلب تطبيقات الSaaS والEnterprise بتبان عادية؟

خلال شغلي السنين اللي فاتت على أنظمة ضخمة، ك Senior software engineer كنت دايماً مهتم جدا بتجربة المستخدم (UX). بنهتم بالألوان والأنيميشن والتصميم، لكن دايماً كان فيه حلقة مفقودة.

المستخدم لما يعمل اي action زي انه يضغط save , or delete أو ينفذ عملية دفع، بيضطر يفضل باصص ومستني التنبيه يظهر. في حين إن المنتجات العالمية بتعتمد على Multi-Sensory Feedback — نغمة رنين خفيفة جداً بتأكد لك النجاح في أجزاء من الثانية.

بس المشكلة: ليه أغلبنا Developers بنتجنب إضافة أصوات؟ عشان صداع ملفات MP3، وحجم التحميل، وبطء استجابة الشبكة (Latency)، ومشاكل SSR في Next.js.


عشان كده قررت أحل الموضوع ده ونشرت مكتبة مفتوحة المصدر بالكامل: Tonely شغال عليها بقالي فتره ولاكن جه الوقت تطلع للنور.. إيه فكرتها؟

Zero Audio Files: مفيش ولا ملف صوتي واحد! كل النغمات بتتولد برمجياً ولحظياً داخل المتصفح (Web Audio API).
سرعة فائقة (Zero Latency): الصوت بينطلق في أقل من 1ms بدون أي Network Requests.
حجم لا يذكر: حجم الحزمة بالكامل أقل من 1.5 KB — أصغر من أيقونة SVG عادية!


جاهزة لModern Web: متوافقة 100% مع Next.js (SSR-safe) و React و Vue وأي إطار عمل، مع نغمات جاهزة ومدروسة لحالات Success وError والتفاعلات اليومية.

لو أنت Frontend أو Full-Stack Developer، أكيد اتكرر معاك السيناريو ده: مستخدم بيرفع صورة من الموبايل تتفاجئ إن حجمها طالع 18MB أو 25MB!

المطورين عادة بيحلوا المشكلة دي بطريقتين: 1️⃣ تحديد حجم upload بـ Validation: وترفض الصورة لو أكبر من 2MB، بس هل المستخدم العادي هيعرف يضغط الصورة بنفسه؟ 2️⃣ الضغط على السيرفر: ترسل الصورة الخام للـ Backend أو تشترك في خدمات زي Cloudinary أو AWS Lambda، وهُنا بتدفع تكلفة وسيرفر أعلى.

طب إيه الحل؟ 💡 بعد ما واجهت المشكلة دي كتير، قررت أطلق مكتبة مفتوحة المصدر جديدة: compressly

ليه تجرّب compressly؟ حجم أقل من 3KB (أخف بـ 95% من المكتبات القديمة زي browser-image-compression). ⚙️ Web Worker مدمج: المعالجة بتتم في الـ Background بدون أي Freeze لـ UI حتّى على الموبايلات الضعيفة. حل اتجاه صور الآيفون (Auto EXIF): معالجة createImageBitmap تضمن إن صورة الـ Portrait متتقلبش بالعرض. 🎯 Adaptive Target Size: بتحدد الحجم المطلوب (مثلاً 0.5MB) وهي بتعدّل الجودة والأبعاد للوصول للهدف. 🚀 دعم Batch: رفع وجدولة عدة صور بالتوازي بدون استهلاك زائد للذاكرة. ⚛️ جاهزة لـ React & Next.js: تدعم SSR ومزودة بـ Custom Hook جاهز.