Bun 1.3.12 طلعت في 9 أبريل 2026 ومعاها فيتشرتين بتغيّر شكل الـ stack: Bun.WebView للـ headless browser و Bun.cron() للـ scheduler جوّا نفس الـ process. لو عندك خدمة بتشغّل Playwright في حاوية منفصلة و node-cron في حاوية تانية، الـ release ده ممكن يشيل حاويتين كاملتين من الـ infra بتاعتك.
Bun 1.3.12: WebView + cron جوّا الـ runtime — اختصر حاويتين من stackك
المشكلة باختصار
الـ stack الشائع للأتمتة في 2026 بيبقى: API container + Playwright container + cron container. تلات services، تلات Dockerfiles، تلات healthchecks، وتلات نقاط فشل. Bun 1.3.12 بتقترح تدمج الاتنين الآخرين جوّا نفس الـ Bun process. المكسب مش في الأداء الخام — المكسب في اختفاء طبقة إدارة infrastructure كاملة.
اللي Bun.WebView بيعمله فعلاً
Bun.WebView هو headless browser مدمج بيشتغل على WebKit افتراضياً أو Chromium اختيارياً. الـ API شبه Playwright: auto-wait على الـ selectors، native OS events، و context isolation. الفرق الأساسي إنه مش بينزّل bundle لـ Chromium حجمه 170MB كل مرة. Bun بيستخدم الـ WebKit المدمج في الـ OS — WKWebView على macOS و WebKit2GTK على Linux.
كود بسيط لسحب عنوان صفحة:
import { WebView } from "bun:webview";
const view = await WebView.launch({ headless: true });
const page = await view.newPage();
await page.goto("https://ahmedhaies.com");
const title = await page.title();
console.log(title);
await view.close();الـ Docker image النهائي لخدمة Bun بتستخدم WebView طولها حوالي 95MB — مقارنة بـ image فيه Node.js + Playwright + Chromium اللي بتعدّي 1.1GB. في Kubernetes بـ 30 replica، ده فرق يقارب 30GB في image storage لوحده، بغض النظر عن سرعة الـ pull في كل deploy.
Bun.cron() — الفرق اللي بيفرق
Bun.cron() بيشتغل جوّا نفس الـ event loop. مش بيفتح process جديد، مش محتاج Redis للـ locking، و الـ release ضمن إن مفيش overlap بين التشغيلات كـ default behavior.
import { cron } from "bun";
cron("*/15 * * * *", async () => {
await sendScheduledReports();
});
cron("0 2 * * *", {
tz: "Africa/Cairo",
onTick: async () => await rotateLogs(),
});السيناريو الواقعي: لو عندك SaaS بـ 200 مستخدم وكل واحد عنده 5 scheduled tasks، الحل القديم كان node-cron + Redis + BullMQ + worker container. مع Bun.cron()، الأربعة بقوا سطر import و loop واحد في نفس السيرفر. قياس من team طبّق ده داخلياً: p95 latency للـ trigger نزل من 340ms لـ 12ms، والذاكرة المستخدمة اتخفّضت بنسبة 62% لأن الـ Redis client و BullMQ workers اتشالوا كلياً.
trade-offs قبل ما تبدّل
Bun.WebView ليه ثمن. الـ WebKit المدمج على Linux (WebKit2GTK) بيختلف عن Chromium في رندر بعض الـ sites. تلاتة من كل عشرة مواقع فيها WebGL ثقيل أو fonts مخصوصة بتبان مختلف. لو بتعمل visual regression testing أو scraping لـ sites بتفرض Chrome fingerprint، Playwright + Chromium لسه أكثر ثباتاً.
Bun.cron() مش free lunch. لو الـ process مات، كل الـ schedules ماتت معاه. مفيش persistence layer افتراضية، فمفيش طريقة تعرف إن task كانت مفروض تشتغل الساعة 2 صباحاً وما اشتغلتش. السيناريو ده ممكن يكون catastrophic في payment reminders أو billing jobs. في الحالات دي، BullMQ + Redis لسه الخيار الصح لأنهم بيوفّروا at-least-once guarantee.
الحسبة بصراحة. بتكسب اختصار 40 إلى 60 بالمئة من الـ infrastructure footprint، بتخسر durability في الـ cron و compatibility كاملة في الـ WebView. لو الشغل بتاعك في الـ 70% الوسطى من الحالات (internal tools، scraping بسيط، scheduled emails للـ marketing)، المعادلة ربح واضح. في الـ 15% الأعلى (compliance-critical scheduling، pixel-perfect automation، billing)، المعادلة خسارة.
متى لا تستخدم هذه الطريقة
متستخدمش Bun.WebView في: visual regression على designs حساسة، scraping sites بتفرض Chrome-specific fingerprints، أو أي flow محتاج browser extensions. متستخدمش Bun.cron() في: workloads بتتطلّب at-least-once guarantee، أو تنظيم بين أكتر من replica (horizontal scaling بيخلّي كل instance يشغّل الـ job مرة، فهتحتاج external locking)، أو schedules طويلة (أكتر من 24 ساعة) حيث فشل الـ process بيبوّظ الـ timing كله.
الخطوة التالية
افتح أي خدمة عندك بتشغّل node-cron أو Playwright في container منفصل. احسب حجم الـ Docker image وعدد الـ processes اللي بتتشغّل فعلاً. لو المجموع أكبر من 800MB أو عندك أكتر من 3 processes مرتبطين بنفس الـ service، الترحيل لـ Bun 1.3.12 ممكن يوفّرلك 30 إلى 50 بالمئة من فاتورة الـ compute الشهرية. جرّب على خدمة واحدة non-critical الأول، قِس لمدة أسبوع، وبعدين قرّر على الباقي.