‏دنو داره راه نود رو می‌ره؟

نویسنده تعریف می‌کنه که سال‌ها با پایتون و هسکل کار می‌کرد و همیشه از تایپ‌اسکریپت فاصله می‌گرفت؛ نه به‌خاطر خود زبون، بلکه به‌خاطر اون همه فایل کانفیگ مثل tsconfig.json و .eslintrc و .prettierrc که باید قبل از نوشتن یه خط کد می‌ساختی. به گفتهٔ اون، دنو این صف طولانی رو حذف کرد: بدون فایل کانفیگ، بدون node_modules، فقط deno run main.ts.

نویسنده می‌گه چیزی که واقعاً جذبش کرد، یه ویژگی خاص نبود؛ بلکه این بود که همه‌چیز تو یه جهت حرکت می‌کرد. همون fetch() مرورگر رو سمت سرور هم داشتی، Web Crypto API همون‌جا بود، و به‌جای نصب پکیج، ماژول‌ها رو با URL ایمپورت می‌کردی. کنار اینا deno fmt و deno lint و deno test و deno check همه تو یه باینری بودن. الگوش ساده بود: روی استانداردهای وب بساز، بعد ابزارهای حوصله‌سربر رو خودت بده.

اما به گفتهٔ نویسنده، دنوی امروز داره از این مسیر دور می‌شه. پشتیبانی از npm:، برگشتن node_modules، سازگاری با ماژول‌های node:، و تو نسخهٔ ۲.۸ حالا deno add به‌صورت پیش‌فرض یه پکیج npm اضافه می‌کنه. نویسنده می‌گه JSR قرار بود جواب دنو به رکود npm و آیندهٔ بسته‌بندی جاوااسکریپت باشه، ولی این تصمیم‌ها اون وعده رو دور و کم‌رنگ نشون می‌دن.

نویسنده برای توضیح خطر، داستان OS/2 رو مثال می‌زنه: IBM فکر می‌کرد اگه سازگاری با ویندوز رو بذاره تو OS/2، کاربرها میان سمتش؛ ولی برعکس شد و توسعه‌دهنده‌ها فهمیدن می‌تونن ویندوز رو هدف بگیرن و رو هر دو اجرا بشه. به گفتهٔ اون، هرچی دنو سازگارتر با نود بشه، نویسنده‌های کتابخونه دلیل کمتری دارن که جداگونه بهش فکر کنن. در همین حال خود نود هم داره سمت دنو میاد: تایپ‌اسکریپت بدون فلگ از نسخهٔ ۲۲، مدل دسترسی از نسخهٔ ۲۰، و fetch() و Web Crypto و node:test.

نویسنده معتقده دنو یه جنگی داشت که می‌تونست رهبریش کنه نه این‌که دنبالش بدوه. به گفتهٔ اون، چیزی که آدم‌ها رو فراری می‌ده خود نود نیست، بلکه کل اون پشتهٔ Node + npm + Vite + ESLint + Prettier + Vitest ـه؛ و دنو با ابزارهای داخلیش داشت خوب جلوش وایمیستاد. بزرگ‌ترین خلأی که مونده سرور توسعه‌ست: HMR، لایو‌ریلود و پایپ‌لاین asset. نویسنده می‌گه ناامیدکننده بود که Fresh 2.0، فریم‌ورک خود دنو، این خلأ رو از داخل دنو پر نکرد و به‌جاش Vite رو انتخاب کرد.

نویسنده می‌گه شاید فقط یکپارچگی عمودی کافی نبود و کیفیت تک‌تک ابزارها هم مهمه؛ اگه deno lint و deno fmt واضحاً بهتر از ESLint و Prettier بودن، آدم‌ها حتی تو پروژه‌های نود هم سراغشون می‌رفتن و این می‌شد اسب تروآ. به گفتهٔ اون، ظاهراً Biome و سری Ox (مثل Oxlint و Oxfmt) دارن همین بازار رو می‌گیرن، یعنی بازارش بود ولی ابزار بهترش نبود.

نویسنده حدس می‌زنه چرا دنو مسیرش رو حفظ نکرد: مسیر جعبه‌ابزار یکپارچه به صبر نیاز داشت، ولی نود یه پروژهٔ جامعه‌محور زیر OpenJS Foundation ـه و ساعت سرمایه‌گذار بالا سرش نیست، در حالی که Deno Land Inc. یه شرکت VC-محوره و ساعتش فرق می‌کنه. اون با همهٔ این گله‌ها می‌گه هنوز طرفدار دنوئه و کتابخونه‌هاش رو Deno-first می‌سازه، ولی خودش هم جاهایی عقب‌نشینی کرده؛ مثلاً حالا برای تست از node:test استفاده می‌کنه و به‌جای Deno KV سراغ node:sqlite رفته.

نکات کلیدی:

• نویسنده می‌گه جذابیت اولیهٔ دنو نبودِ کانفیگ، تکیه بر استانداردهای وب و جعبه‌ابزار یکپارچه بود
• به گفتهٔ اون دنو با پشتیبانی از npm و node_modules و node: داره انرژیش رو خرج سازگاری با نود می‌کنه
• تو نسخهٔ ۲.۸، deno add به‌صورت پیش‌فرض پکیج npm اضافه می‌کنه
• نویسنده با مثال OS/2 می‌گه سازگاری بیشتر، دلیل کمتری برای انتخاب مستقیم دنو می‌ذاره
• انتخاب Vite توسط فریم‌ورک Fresh 2.0 به‌جای پر کردن خلأ سرور توسعه از داخل دنو، نویسنده رو ناامید کرده