هشدار خالق جاوااسکریپت: ویندوز 11 با حذف برنامههای Native، سرعت و کیفیت را نابود میکند!
هشدار خالق جاوااسکریپت: ویندوز 11 با حذف برنامههای Native، سرعت و کیفیت را نابود میکند!
از دیسکورد و تیمز گرفته تا واتساپ، جستوجوی ویندوز، منوی استارت و حتی بخش جدید Agenda در مرکز اعلانها؛ ویندوز ۱۱ با لجاجت تمام در حال پر کردن گوشه و کنار سیستمعامل با «زبالههای وب» است.
به گزارش اپست به نقل از windowslatest ، این وضعیت آنقدر از کنترل خارج شده که حتی برندان آیک، خالق جاوااسکریپت و مرورگر Brave نیز از این رویکرد به شدت انتقاد کرده است.
مطالب مشابه: اخبار ویندوز 11
ویندوز ۱۱ اخیراً به دلایل کاملاً اشتباهی در صدر اخبار قرار گرفته است. چندی پیش در مطلبی نوشتم: «مایکروسافت بازنویسی ویندوز ۱۱ با هوش مصنوعی را تکذیب کرد». هدف اصلی آن مطلب، رد ادعای بازنویسی ویندوز با زبان Rust و هوش مصنوعی بود، اما از آن فرصت استفاده کردم تا به مشکل بزرگتری اشاره کنم:
مطالب مشابه: اخبار ویندوز
ویندوز ۱۱ به شکلی فزاینده در حال وابستگی به فریمورکهای وب، بهویژه WebView2 و Electron است.
این بخشی از تلاش من بود تا موضوع «بیکیفیت شدن ویندوز ۱۱ به دلیل اشباع با محتوای وب» را به یک جریان خبری بزرگ تبدیل کنم تا افراد بیشتری متوجه آن شوند.
در کمال تعجب، این موضوع توجه برندان آیک، خالق جاوااسکریپت و مدیرعامل Brave را جلب کرد. این اسطوره دنیای برنامهنویسی که بنیانگذار سیستمعامل B2G (همان فایرفاکس OS) بوده و در پروژه webOS نیز نقش داشته است، لب به اعتراض گشود.
«آیک» استدلال میکند که با این حجم از سنگینی و کُندی (Bloat) مخالف است؛ چرا که مایکروسافت به جای استفاده از رابط کاربری بومی (Native)، با عجله به سراغ رابط کاربری وب رفته است. او معتقد است که اپلیکیشنهای تحت وب را میتوان «درست و اصولی» طراحی کرد، اما این کار زمانبر است؛ چیزی که اکثر شرکتها تمایلی به صرف آن ندارند.
برندان آیک در پستی در شبکه اجتماعی X نوشت: «نکته پنهان داستان اینجاست که ویندوز ۱۱ مشکل بزرگی دارد و آن چیزی نیست جز WebView2 یا Electron. من به عنوان یکی از بنیانگذاران FirefoxOS، با این سنگینیِ ناشی از جایگزینی عجولانه وب به جای محیط بومی مخالفم. این کار پتانسیل درست انجام شدن را دارد، اما زمان میبرد.»
در یک گفتگوی جنجالی، کاربری استدلال کرد که تمرکز بر WebView صرفاً ابزاری برای «کنترل بیشتر» و عادت دادن کاربران به مدلهای اشتراکی (Subscription) است. اما برندان آیک (خالق جاوااسکریپت) با این منطق مخالفت کرد و پرسید: «تقابل وب در برابر اپلیکیشنهای بومی (Native) چطور میتواند به این برنامه کمک کند؟»
آیک معتقد است: «اتفاقاً قفل کردن کاربر (Lock-in) در اپلیکیشنهای Native بسیار آسانتر است.» به عبارت دیگر، اگر ترس ما از انحصار و وابستگی باشد، اپلیکیشنهای تحت وب لزوماً بهترین گواه برای این ادعا نیستند.
سپس آیک نگاه خود را از بحث تکراری «وب در مقابل نیتیو» فراتر برد و ریشه اصلی مشکل را در انگیزههای تجاری دانست. او وضعیت فعلی را حرکت به سمت «مدل اشتراکی به جای مالکیت دائمی» توصیف کرد و آن را به پدیده Enshittification (نزول کیفیت برای سود بیشتر) پیوند داد؛ تاکتیکی که با بدهیهای مالی و سیستمهای مدیریت حقوق دیجیتال (DRM) پیش میرود؛ درست مثل مثال معروف «تراکتورهایی که فقط با اجازه سازنده کار میکنند!»
آیک حتی تا جایی پیش رفت که NPM را یک اشتباه خواند. برای کسانی که نمیدانند: NPM (مدیریت بستههای نود) کتابخانه عظیمی است که به توسعهدهندگان اجازه میدهد از کدهای آماده جاوااسکریپت استفاده کنند.
وباپلیکیشنها؛ اگر قرار است اجباری باشند، حداقل باید «درست» طراحی شوند
وباپلیکیشنها ذاتاً بد نیستند، به شرطی که در جای درست و با کیفیت بالا ساخته شوند. واقعیت این است که برای هر چیزی (حتی بخش سادهای مثل Notification Center ویندوز) نیازی به استفاده از تکنولوژیهای وب نیست.
اگر مایکروسافت واقعاً اصرار دارد همهچیز را بر پایه وب بنا کند، باید کیفیت اجرا و پیادهسازی آن را ارتقا دهد. این موضوع در مورد تمام غولهای فناوری، از جمله متا نیز صدق میکند.
دیسکورد؛ نمونهای از بلعیدن منابع سیستم توسط اپلیکیشنهای Electron
اگر به دیسکورد نگاه کنید، میبینید که وقتی مصرف رم آن به ۴ گیگابایت میرسد، به جای سوییچ به کدهای بهینه نیتیو، تلاش میکند اپلیکیشن را ریاستارت کند! این در حالی است که آنها همچنان در حال کلنجار رفتن با بهینهسازی فریمورک Electron هستند.
دیسکورد در بیانیهای اعتراف کرد که نسخه دسکتاپ آن در ویندوز ۱۱ از نظر مصرف رم اصلاً بهینه نیست؛ آن هم در دورانی که پیشبینی میشود قیمت حافظه رم به شدت افزایش یابد.
بله، ما در حال تست قابلیتی هستیم که وقتی مصرف حافظه (RAM) از ۴ گیگابایت فراتر میرود، اپلیکیشن را ریاستارت کنیم؛ در حالی که مصرف عادی باید زیر ۱ گیگابایت باشد.» این جملهای است که یکی از کارمندان دیسکورد در انجمنهای گفتگو منتشر کرده و توسط رسانهی Windows Latest رصد شده است.
بهدنبال اعتراض کاربران، دیسکورد توضیح داد که این ریاستارت خودکار فقط در شرایطی رخ میدهد که کاربر به مدت ۳۰ دقیقه هیچ فعالیتی با کیبورد یا موس نداشته باشد یا در میان یک تماس صوتی/تصویری فعال نباشد.
دیسکورد به سراغ کدنویسی Native نمیرود!
برخلاف انتظار برخی کاربران، دیسکورد برنامهای برای جایگزینی فریمورک Electron با کدهای نیتیو (Native) ندارد. در حقیقت، این شرکت مدعی است که توانسته مصرف رم را برای اکثر کاربران کاهش دهد؛ هرچند هنوز هم این اپلیکیشن در حالت بیکار (Idle) به راحتی ۱ گیگابایت از رم را اشغال میکند.
تیم فنی دیسکورد در این باره میگوید:
«برخی کاربران شاهد کاهش اعداد مصرفی نسبت به قبل هستند. به طور کلی، ما تاکنون ۵٪ کاهش در مصرف حافظه (در صدک p95) داشتهایم، اما هنوز کارهای زیادی برای انجام دادن باقی مانده است.»
این شرکت همچنین ریشهی برخی مشکلات را در لایههای عمیقتر مثل سیستمعامل، درایورها و سختافزار پیدا کرده و با همکاری شرکای تجاری، در حال ارائهی اصلاحیههایی برای آنهاست.
واتساپ و تیمز؛ شرکای جُرم در اشغال حافظه
دیسکورد در این مسیر تنها نیست. مایکروسافت تیمز و واتساپ نیز وضعیتی مشابه دارند و اغلب بیش از ۱ گیگابایت رم مصرف میکنند. تفاوت اصلی در اینجاست که برخلاف دیسکورد که از Electron استفاده میکند، تیمز و واتساپ بر پایهی WebView2 طراحی شدهاند.
WebView2 (که بر پایه کرومیوم است) به دلیل ادغام با ویندوز، کمی بهینهتر از Electron عمل میکند. با این حال، متأسفانه مایکروسافت تیمز همچنان با مشکلاتی مثل مصرف بالای رم، افت عملکرد و تجربهی کاربری ضعیف دستوپنجه نرم میکند.
مایکروسافت اخیراً اعتراف کرده که «تیمز» (Teams) با مشکل جدی در عملکرد روبروست؛ اما جالب اینجاست که به جای حل ریشهای ماجرا، صورتمسئله را پاک کرده است! این شرکت قصد دارد فرآیند تماسهای تیمز را در یک فایل اجرایی (exe.) جداگانه قرار دهد تا کُندیِ هستهی اصلی برنامه، روی تماسها تاثیر نگذارد.
واتساپ نیز مسیر مشابهی را طی میکند. این اپلیکیشن اخیراً نسخه نیتیو (Native) خود در ویندوز را به WebView2 تنزل داده است؛ نتیجه؟ حالا واتساپ در ویندوز ۱۱ به راحتی ۱ گیگابایت از رم سیستم را میبلعد!
نکته عجیب اینجاست که واتساپ در ابتدا یک نسخه تحت وب (Electron) بود، اما متا آن را به کدنویسی نیتیو (WinUI/XAML) تغییر داد. حالا پس از سالها سرمایهگذاری روی فریمورکهای اختصاصی ویندوز، متا عقبنشینی کرده و با رها کردن کدنویسی نیتیو، دوباره به سراغ WebView2 رفته است. اما آیا این بحرانِ «فریمورکهای وب» فقط محدود به اپلیکیشنهاست؟ خیر؛ این یک چالش بزرگ برای کل اکوسیستم ویندوز ۱۱ است.
بخش «پیشنهادات» در منوی استارت ویندوز ۱۱ همین حالا هم از React Native استفاده میکند، اما ماجرا به اینجا ختم نمیشود. مایکروسافت در حال اضافه کردن نمای Agenda (برنامه روزانه) به بخش نوتیفیکیشنهاست که بر پایه WebView2 طراحی شده؛ در حالی که همین ویژگی در ویندوز ۱۰ به صورت کاملاً محلی (Native) اجرا میشد.
اگر سری به Task Manager بزنید، متوجه عمق فاجعه خواهید شد: با فعال شدن این قابلیت، مصرف رم فرآیندهای مربوط به مرورگر Edge ناگهان از ۱ مگابایت به ۱۰۰ مگابایت جهش پیدا میکند!
شاید استفاده از فریمورکهای وب برای یک توسعهدهنده مستقل که قصد ساخت یک اپلیکیشن چندپلتفرمی را دارد، منطقی باشد؛ اما وقتی درباره غولی مثل مایکروسافت با ارزش ۳.۵ تریلیون دلار صحبت میکنیم، پذیرفتنی نیست که نتواند برای سادهترین بخشهای ویندوز ۱۱ — مثل نمای تقویم (Calendar Agenda) — یک رابط کاربری بومی (Native) طراحی کند.
این روند واقعاً باید متوقف شود. نظر شما چیست؟ در بخش نظرات برایم بنویسید.
برای دسترسی به جدیدترین مطالب کامپیوتر کلیک کنبد
