Bun 1.3.12: WebView + cron جوّا الـ runtime — اختصر حاويتين من stackك

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 اتشالوا كلياً.