Цены на ОЗУ растут, а популярные приложения для Windows 11 пожирают её из-за Electron и веб-компонентов

🚀

Знаете, что сейчас происходит с нашим любимым Windows 11? Многие приложения, которыми мы пользуемся каждый день, жрут оперативку как не в себя! 😱 И это всё при том, что цены на её покупку сейчас кусаются. Виноваты в этом любители разработчиков делать из десктопных программ обычные веб-сайты, завернутые в красивую обертку.

Недавно заметил, что такие монстры, как Discord, Teams и даже новенький WhatsApp, могут спокойно улететь в гигабайты ОЗУ, даже когда они просто висят в фоне. 🤯 Казалось бы, это же мессенджеры, им надо быть всегда на связи, но раньше-то они такими прожорливыми не были! Старые версии WhatsApp, например, работали нативно и не доставляли таких проблем.

Почему же разработчики не делают свои приложения нативно под Windows? Неужели так сложно? 🤔

Сейчас, когда память стала дорогим удовольствием, а некоторые производители вообще убирают её из своего ассортимента, это особенно больно. 🤔 Windows 11 и так при запуске ругали за повышенные требования к ОЗУ, а тут ещё и приложения начали её так активно потреблять.

Discord: 1 ГБ в простое и 4 ГБ на максимум! 💥

Discord — это отдельная история. Сами разработчики признают, что их приложение объёмное. Оно построено на Electron, а это, по сути, целый браузер Chromium плюс Node.js, запакованные в десктопную программу. Каждый сервер, каждый канал, каждая новая фича — это как новая вкладка в этом браузере.

Обещают, что обычно оно под 1 ГБ, но в реальной жизни может и до 4 ГБ улететь. Именно поэтому они даже экспериментировали с автоматической перезагрузкой, если память превысит 4 ГБ. 😴 Если приложение открыто час, вы были неактивны полчаса и не в звонке — оно может тихо перезапуститься раз в сутки. Типа, чтобы память освободить. Это, конечно, хорошо, но это скорее временное решение, чем исправление самой сути проблемы. Electron — это полноценный браузерный движок для каждого приложения. Зачем нам движок, рантайм JS и песочницы просто для чата?

Хорошо, что Discord пытается что-то исправить. Плохо, что компания, несмотря на 10 лет существования, не сказать чтобы очень прибыльная. Так что ждать нативное приложение ждать, скорее всего, не стоит. Они даже на macOS нативное приложение не сделали.

WhatsApp: от быстрой нативной версии к тормозному веб-огрызку 🐌

WhatsApp — это вообще другой уровень печали. Раньше была отличная UWP-версия, шустрая, легкая. По сотням чатов и групп она максимум 250 МБ съедала.

А теперь? Meta сделала новую версию как WebView2 — это просто веб.whatsapp.com, запущенный в хроме. 🤦‍♂️ Перед логином приложение уже потребляет около 300 МБ! А как только синхронизация начнётся и начнешь листать переписки, так все 1.2 ГБ, а то и больше! И процессор тоже на пределе.

Проблемы не только с ОЗУ. Интерфейс стал медленнее, переключение между чатами с задержкой, постоянное ощущение "тяжести". И закрытие окна не выключает приложение — оно просто сворачивается в трей и продолжает жрать память для уведомлений. 🙄

Всё это ради "упрощения разработки" и переиспользования кода. Но для пользователей это прямой даунгрейд. На macOS у Meta до сих пор нативное приложение. А на Windows, где пользователей гораздо больше, они скатываются до браузерной обертки. Просто лень какая-то, при их-то возможностях!

Teams: даже Microsoft не парится 🤷‍♂️

А Microsoft Teams? Да, они ушли от Electron к WebView2. Звучит как прогресс, да? Но по сути, это всё та же веб-приложение. Teams в простое спокойно держит около 1 ГБ ОЗУ.

Microsoft признает проблему, но вместо переписывания, они решили реструктурировать. Скоро появится новый процесс ms-teams_modulehost.exe, который будет заниматься звонками отдельно от основного. Но суть не меняется: всё это работает поверх WebView2.

Что тут скажешь, когда даже сама Microsoft, чьи клиенты в основном и пользуются Teams, не особо этим морочится? 🤦‍♂️

Так почему же все современные приложения так много жрут ОЗУ?

Большинство новых приложений в Microsoft Store — это не совсем "виндовые" приложения, а браузеры. Discord — Electron, WhatsApp и Teams — WebView2, куча мелких — PWA. Все они используют встроенный движок Chromium.

Каждое Electron-приложение тащит за собой свой движок JavaScript, рендерер GPU, сетевой стек, аудио и кучу процессов. Даже маленький элемент UI может создать отдельный процесс из-за современных стандартов безопасности браузера. Каждая чат, сервер, канал, звонок — это отдельный "песочница". Память растёт горизонтально, когда функции работают параллельно.

WebView2, конечно, лучше Electron, так как не запускает новую копию Chromium, а использует уже установленный Edge. Но принцип тот же. Даже обычный список чатов в новом WhatsApp — это мини-вкладка Chrome со всеми её слоями.

PWAs, типа Reddit-приложения, работают так же.

Технически, WebView2 всё же лучше Electron

Electron запускает каждое приложение как отдельный браузер, что увеличивает вес и потребление ОЗУ, но обеспечивает кроссплатформенность. WebView2 же использует установленный Microsoft Edge, что снижает накладные расходы. Минус — он привязан к Windows и требует наличия Edge.

Но вообще-то, такая архитектура не случайна. Разработчики делают это для безопасности. Современные браузеры изолируют процессы, чтобы вредоносные страницы не могли взаимодействовать с вашими данными. Они разделяют память, чтобы изолировать рендеринг от логики, а логику от хранения данных. Это цена за безопасность. Так что лишнее потребление ресурсов — это неизбежность, когда выбираешь браузерный движок как основу для десктопного приложения.

Плюс ещё современные JavaScript-фреймворки добавляют свою ложку мёда (или дёгтя). Тяжёлые сборки, алгоритмы сравнения, виртуальный DOM, клиентские машины состояний — всё это поверх и так немалого потребления браузера. Даже хорошо оптимизированные веб-обертки имеют высокий базовый расход памяти.

Утечки памяти повсюду 💧

Утечки памяти случаются, когда ссылки на JavaScript не освобождаются правильно, или когда со временем накапливаются слушатели событий. Часто фреймворки кешируют объекты, даже если они не нужны. Или когда процессы браузера не освобождают память в долгих сессиях.

Начинается всё с малого, а потом превращается в гигабайтные скачки, как у Discord. Это частая проблема для Electron, CEF и WebView2. А отладка таких сложных JS-стеков далеко не так продвинута, как для нативных приложений.

Честно говоря, компании мониторят потребление памяти, но всё, что они могут сделать — это выкатывать патчи, которые исправляют отдельные мелкие проблемы. Но вся эта система очень сложна, и многое скрыто за абстракциями. Вы не видите, что Chromium делает на низком уровне. Вы не можете заставить его рендерер агрессивнее освобождать память. Вы не можете переписать многопроцессную модель. Есть лимит на то, насколько можно оптимизировать фреймворк под потребление памяти.

Почему компании продолжают делать веб-приложения вместо нативных?

Учитывая все эти проблемы, почему компании всё равно делают веб-приложения? Неужели им плевать на плавность работы?

Самый простой ответ — стоимость. Один и тот же код на JavaScript может работать на Windows, macOS и Linux с минимальными изменениями. Гораздо проще нанять JavaScript-разработчиков, чем C++. Новые сотрудники быстрее входят в курс дела, циклы разработки короче. Команды могут одновременно выпускать фичи на всех платформах. Большинство компаний спешат выпустить свои приложения быстрее, и в такой ситуации разработка нативных приложений не всегда практична.

Компании также говорят о "единообразии бренда". Но это, честно говоря, глупо. Идея в том, чтобы их интерфейс выглядел одинаково везде. Веб-обертки это позволяют. Но у разных ОС разные стили, хотя в Windows это другая история. На macOS, например, есть Liquid Glass дизайн. Весь интерфейс ОС в этом стиле, а если приложение выглядит иначе, это портит впечатление.

Самое печальное — компании больше не считают нативные приложения для Windows приоритетом. Meta убрала UWP-версию WhatsApp, хотя она и работала хорошо. Messenger вообще исчез из Microsoft Store. Facebook и Instagram теперь — веб-обертки.

Даже Microsoft не подает пример: Teams остаётся WebView2-приложением, а LinkedIn (который они купили за $26.2 млрд) — это просто веб-обертка.

И что забавно — даже новая панель уведомлений в Windows 11 с "Agenda view" использует WebView2 вместо нативного XAML/WinUI. То есть, часть самой операционки сделана как веб-обертка, которая к тому же потребляет больше памяти при взаимодействии. Стоит ли после этого винить Meta и других?

Apple наслаждается более оптимизированным и нативным каталогом приложений 🍎

Пользователи Apple гораздо более требовательны к приложениям. Они хотят быстрый, плавный нативный опыт. Это заставляет разработчиков вкладываться в нативные macOS-приложения, даже если это дороже. Разработка на macOS сама по себе не менее сложна.

Удивительно, но разработка нативных приложений для Windows проще, чем для macOS. Microsoft предоставляет единую экосистему с зрелыми фреймворками, такими как .NET, WPF и UWP/WinUI. Все они тесно интегрированы с Visual Studio и имеют отличную обратную совместимость.

Разработка на macOS требует работы с Cocoa и Swift/Objective-C API через Xcode, с более строгими правилами песочницы, подписи и распространения через App Store. Разработчики Windows имеют доступ к более широкой поддержке языков с меньшим количеством ограничений. Ожидаемо, у разработчиков macOS более крутая кривая обучения из-за жесткой экосистемы Apple и использования специфичных API.

Но пользователи Windows уже привыкли к веб-софту, и разработчики это знают. Пока приложение работает, пусть и медленнее, негатив обычно небольшой. Поэтому компании вкладывают меньше.

Все дело в изначальной позиции Apple не выпускать бюджетные ПК. Сейчас большинство их клиентов имеют более высокую покупательную способность, и вся компания воспринимается как люксовый бренд. Именно поэтому будущий бюджетный MacBook может создать серьезную головную боль производителям ПК.

Убедить компании и их разработчиков писать нативный код только ради оптимизации и меньшего потребления ОЗУ становится нереалистичным, когда браузерная модель дешевле, может быть выпущена где угодно, а пользователи не так сильно жалуются.

Цены на ОЗУ растут, и это не изменится 📈

Время, выбранное для всего этого, худшее некуда. Цены на ОЗУ практически удвоились во многих случаях, в основном из-за сокращения поставок обычным потребителям, агрессивных ценовых циклов DDR5 и, конечно же, огромного спроса со стороны дата-центров для ИИ. Производители памяти теперь отдают приоритет этим высокомаржинальным корпоративным чипам.

Нет никакого волшебного решенияcurrent ситуации с приложениями для Windows. Microsoft должна сыграть ключевую роль. Мы не видим никаких выгод для других разработчиков. Компания могла бы вернуть разработчиков к нативным инструментам, усовершенствовать WinUI, чтобы сделать его более привлекательным, и показать, что качество ядра системы всё ещё имеет значение, исправляя давние проблемы в Windows.

Если Windows собирается существовать в мире, построенном на браузерных приложениях, платформа должна сначала показать пример и дать пользователям и разработчикам лучшую основу для работы.

Цены на ОЗУ растут, а приложения всё больше её потребляют. Основная причина — переход разработчиков на кроссплатформенные веб-технологии (Electron, WebView2) вместо нативных решений. Это удешевляет разработку, но ухудшает пользовательский опыт и увеличивает нагрузку на систему, особенно в условиях роста цен на память. Microsoft, похоже, не спешит менять ситуацию, и пока неясно, будет ли эта тенденция меняться.