Современное оборудование невероятно быстрое. M1 Max, на котором я пишу эту статью, работает с частотой 3,2 ГГц. То есть 3,2 МИЛЛИАРДА тактов в секунду. Однако Microsoft Teams требуется 3 секунды, чтобы открыть ссылку, и я отказываюсь верить, что для открытия ссылки требуется 9,6 МИЛЛИАРДА тактов. Очевидно, я упрощаю, но смысл остаётся прежним: как так получается, что оборудование становится быстрее, а приложения — только медленнее?

«Потому, что мы выполняем гораздо больше задач». Так считает любитель позднего капитализма. Позвольте объяснить.

Превосходный пример мощи современного «железа» — это видеоигры. Я могу симулировать огромные 3D-среды с физикой и освещением, полученным трассировкой лучей, при этом играть в реальном времени с друзьями из других штатов и даже стран; вполне доступный компьютер потребительского уровня выдаёт 124 миллиона пикселей в секунду1.

[1. 1080p при 60 FPS = 1920 × 1080 × 60 = 124416000]

Можно посмотреть и в обратном направлении: людям удаётся запускать DOOM на почти любом устройстве с процессором: на калькуляторах, iPod, фотокамерах. Невероятно маломощные, зачастую одноразовые устройства обладают достаточными вычислительными ресурсами, чтобы выполнять сверхсовременную на 1993 год игру. Это не особо удивляет, ведь прошло три десятка лет, но показывает, какой путь мы проделали.

«Веб плохой»

Веб крутой. На самом деле, веб настолько крут, что находится в собственном классе обратной совместимости, кроссплатформенности и доступности. Кроме того, у веба есть модель на основе событий, сильно упрощающая написание UI. Разумеется, за это удобство тоже приходится расплачиваться: скоростью. Выполнение настолько гибкого языка, как JS — само по себе сложная задача, и, вероятно, именно его вы в первую очередь будете винить, сравнивая быстрое нативное приложение с тормозной веб-версией. Конечно, интерпретируемый язык с динамической типизацией неизбежно требует больше памяти и работает медленнее.

В некоторых случаях JS заслуживает критики. Например, webpack должен парсить тысячи файлов, создавать AST и выполнять непонятные мне полностью сложные вещи, требующие больших ресурсов процессора, поэтому логично, что esbuild (Go) и swc (Rust) справляются с этим гораздо быстрее, чем webpack.

Однако в случае веб-приложений общего назначения это не так; веб — не причина того, что ваше великолепное приложение для IRC-чатов работает с частотой 5 FPS. Пару недель назад в Twitter вспоминали каталог сайта McMaster-Carr. Благодаря агрессивной предзагрузке и рендерингу на стороне сервера веб-сайт и навигация по нему работают невероятно быстро, несмотря на использование технологий, которым уже десятки лет (ASP.NET, jQuery). Любители всего нового посрамлены.

Если вы ненавидите React, то это может показаться отличным аргументом против React и других «современных» JS-фреймворков, но это совершенно2 неверный вывод. Зацените NextFaster (репозиторий) — столь же быстрая копия каталога McMaster, а то и превосходящая его по скорости, написанная на Next.js с хостингом на Vercel.

[2. Да, существует аргумент о «башне сложности» и бесконечные абстракции, которые мы создаём, чтобы просто выводить поля на экран, но этот аргумент не относится к производительности. Можно писать быстрые приложения практически на чём угодно.]

Вероятно, воплощением веб-технологий стала Figma. Если задуматься, то полнофункциональный дизайнерский инструмент, работающий в 60 FPS с «мультиплеером» в реальном времени — это просто безумие. Хотя, если честно, это не полностью JS, большая часть приложения работает на WebAssembly и WebGL. Могли они выжать ещё больше производительности из нативного приложения? Возможно. Но для этого пришлось бы отказаться от удобства веб-сайта, для работы с которым достаточно на него зайти. Вместо этого разработчики приложили все усилия к оптимизации и доказали, что браузер может демонстрировать настоящую мощь.

Примечание: огромная благодарность разработчикам V8, SpiderMonkey и JavaScriptCore за то, что всё это стало возможно. Именно благодаря вашему кропотливому труду мы вообще можем что-либо создавать.

«Electron плохой»

Примечание: здесь я подразумеваю сам Electron, CEF, WKWebView, Edge WebView2 и все остальные обёртки для превращения веб-приложений в нативные.

Electron позволил писать веб-приложения и преобразовывать их в десктопные. Это несомненно привлекательная возможность. Теперь можно нанять разработчиков с одним набором навыков, написать один раз одно приложение и создавать «десктопные» приложения для каждой архитектуры и операционной системы (да, даже для Linux).

Чем же пришлось за это расплачиваться? Единственный надёжный способ запуска веб-приложений — через веб-браузер, поэтому в Electron просто… есть веб-браузер. Что может пойти не так? ¯\_(ツ)_/¯

Оказывается, многое. За последний десяток лет стало социально приемлемым то, что размер скачиваемых приложений превышает 500 МБ, а сами они требуют огромного количества ОЗУ и ресурсов CPU, при этом быстро разряжая аккумуляторы устройств. Но даже несмотря на высасываемые ими ресурсы, ими не так уж удобно пользоваться. Ненативность очень многих приложений «протекает» через странное поведение скроллинга и выделения, внешний вид и управление навигацией, не говоря уже об ужасной тормознутости при смене экранов. Discord и Teams — отличные примеры такой Electron-ификации. У них обоих есть отличные мобильные приложения, но десктопные — это просто переупакованный веб-сайт. Зачем?

Но винить в этом Electron будет не совсем справедливо. Electron просто сказал: «Есть способ поместить ваше веб-приложение в окно».

Настоящие виновники — компании, создающие эти приложения. Хорошие Electron-приложения создавать определённо можно, лучшие примеры — это Slack, Obsidian и Notion. Достаточно просто быть ответственными.

Посвящённый Electron раздел не был бы полным без упоминания BracketsAtom и, главное, VS Code. Честно говоря, меня впечатляет, насколько хорошо работает VS Code, учитывая то, что редактирование больших файлов на JS похоже на стрельбу себе в ногу с последующим участием в марафоне: вы что-то докажете, но не совсем понятно, что.

Большая доля успеха VS Code, безусловно, связана с его экосистемой плагинов, и это не в последнюю очередь вызвано доступностью веб-стека. Недавно я написал плагин для SWC, и с уверенностью могу сказать, что степень удобства разработки (developer experience, DX) нативных плагинов и близко не стоит со сверхбыстрыми циклами итераций веба.

«Нативность плоха»

Мои пренебрежительные отзывы о веб-технологиях могут составить впечатление, что я люблю нативные приложения. Большинство нативных приложений замечательно в использовании (PosticoZed), и я по возможности стараюсь пользоваться ими.

Перейдя пару месяцев назад на Zed, я уже не вернусь к VS Code. Всё в нём (действительно всё) происходит мгновенно. Вы можете думать, что VS Code и так «достаточно быстр», но это как сравнивать скорость звука со скоростью света. Разница едва ощущается, но в ней-то и весь смысл. Как Zed удалось этого добиться? Разработчики написали собственный GPU-фреймворк с нуля и создали редактор целиком на Rust. Когда используешь современное оборудование с умом, оно по-настоящему быстрое. Кто бы мог подумать?

Мне бы хотелось изучить глубже React Native для десктопов. Похожая на DOM модель рендеринга RN импонирует мне как веб-разработчику; к тому же мне кажется, что она обеспечивает нужный баланс между отличным DX и производительностью, особенно с New Architecture. Пока мне не очень понятно, почему RN для десктопов не особо популярен, ведь теоретически он выглядит как идеальный баланс (хотя причиной может быть недостаточно качественная поддержка со стороны разработчиков RN).

К сожалению, в мире нативности тоже не всё хорошо. Продукты Adobe славятся своими частыми вылетами. Меню поиска в Windows 11 смехотворно плохое. Activity Monitor в macOS требуется 5 секунд на составление списка работающих программ.

Так что же, мы обречены?

Очевидно, что эти проблемы не связаны с конкретным языком программирования, операционной системой или отраслью. Причина в более обширном тренде выпуска «быстрее и хуже». Скорость выпуска важнее, чем качество.

Трагедия общин

Ситуация особенно ухудшилась в последние годы, потому что современные компьютеры стали гораздо быстрее, чем требуется среднестатистическому человеку. Если начать прокручивать YouTube Shorts в десктопном браузере, то начнутся утечки ОЗУ (более 2 ГБ!) и наконец всё упрётся в ограничение ресурсов. Подобное было бы немыслимо в былые времена, когда у компьютеров было всего 2 ГБ ОЗУ. Кажущиеся неограниченными вычислительные ресурсы современных машин становятся оправданием для создания менее качественного ПО.

Уловка «приемлемости»

Как вы заметили, мне очень важно, чтобы программами было удобно пользоваться, но после общения с разными людьми я осознал, что такой подход не так уж популярен. Большинство людей устраивает, когда нужно ждать 500 мс появления контекстного меню после нажатия на правую клавишу мыши, и они не замечают торможений при изменении размеров окна. Это или привычка с тех времён, когда для загрузки изображения нужно было ждать 15 секунд, или выученная беспомощность перед плохим user experience. Но мы можем повысить качество, у нас есть технологии.

Культура «Ship It»

Можно создавать проекты, и создавать их быстро. Этой статьёй я не хочу обвинять кого-то в быстрых итерациях с новыми идеями, но существует огромная разница между тем, чтобы считать снижение производительности техническим долгом, и полным игнорированием производительности. Кажется, что во многих программах, которые мы используем каждый день, о производительности не задумывались даже после их выпуска; похоже, разработчики просто ждут, пока мощности оборудования догонят их потребности. Такой подход допустим, если вы создаёте что-то сверхпрогрессивное, но если ваша задача — вывести текст на экран, то я вряд ли с вами соглашусь.

Производительная производительность

Из прочтения этой статьи можно прийти к выводу, что я рекомендую оптимизировать всё вплоть до отдельных команд CPU. Хотя это само по себе было бы впечатляющим результатом, для большинства ПО это совершенно нереализуемо (если только вы не Крис Сойер, разрабатывающий RollerCoaster Tycoon). Эта статья не о производительности ради производительности. Просто я осознал, что разработчики крупномасштабного современного ПО, похоже, почти не заботятся об удобстве его использования, потому что вы всё равно будете им пользоваться. Не к такому будущему я стремлюсь.

Если вы разработчик ПО, то я призываю вас создавать его, стремясь к точности и качеству. Уделяйте внимание миллисекундам. Цените то, что вам нравится использовать. Держите планку своего ремесла и гордитесь им.

Хватит тратить большее на меньшие возможности.

Комментарии (38)


  1. diakin
    05.11.2024 08:35

    Tragedy of the Commons - это не "трагедия общин" здесь.


    1. SadOcean
      05.11.2024 08:35

      Это обыкновенный неудачный перевод, но часто используемый.
      Правильнее пожалуй "трагедия общих ресурсов"


      1. janatem
        05.11.2024 08:35

        Нет, эта ошибка есть и в оригинале. Просто автор употребил всуе занятый термин. Я тоже прицепился к этому месту, ожидая в этом разделе разъяснение того, как именно возникает феномен трагедии общин. Например так: в основном «пипл хавает», так что каждому производителю в отдельности экономически невыгодно улучшать качество, а та часть пользователей, которая «не хавает», не может существенно повлиять на рынок; в результате возникает петля положительной обратной связи, из-за которой всем становится хуже.


        1. janatem
          05.11.2024 08:35

          Есть еще забавный пассаж насчет того, что веб находится в собственном классе (и в оригинале так же). Узнаю брата математика! На этот раз термин употреблен более-менее корректно, хотя читатель ничего не потеряет, если не распознает отсылку.


        1. SadOcean
          05.11.2024 08:35

          Так ровно этот эффект и описывается, не?
          Каждому отдельному приложению нет смысла оптимизироваться - оно работает достаточно хорошо. Оптимизация самого приложения не улучшит экосистему в целом (потому что другие приложения останутся тормознутыми) и не улучшит сильно позиции приложения (потому что если твое приложения быстрое, а остальные помедленнее - с точки зрения пользвателя все +- так же)

          Соответственно буквально "трагедия общин".

          Но сам по себе термин трагедия общин является плохим переводом ровно в контексте того примера с полем. Речь не о деревне, речь о поле, общем ресурсе.


          1. janatem
            05.11.2024 08:35

            Конечно, здесь идет речь именно об этом понятии. Забавно, но мы в своих комментариях оба дописываем текст за автора, добавляя пояснение, почему употребление термина «tragedy of the commons» уместно — как обнаруживается это явление в ситуации, описываемой в статье.

            Что касается перевода, то я воспринимаю «трагедию общин» как исторический, пусть не совсем точный, термин, описывающий понятие из теории игр. В википедии, кстати, используются оба варианта, просто «трагедия общих ресурсов» выбрана в качестве основного.


  1. Akina
    05.11.2024 08:35

    Однако Microsoft Teams требуется 3 секунды, чтобы открыть ссылку, и я отказываюсь верить, что для открытия ссылки требуется 9,6 МИЛЛИАРДА тактов.

    И не надо. MS Teams послала запрос в сеть, и пока ей доставят ответ - сидит и курит бамбук. А такты тикают...


    1. Revertis
      05.11.2024 08:35

      MS Teams послала запрос в сеть

      MS Teams послала запрос системы аналитики о том, что приложение запустили, в сеть и ждёт.


  1. Lazhu
    05.11.2024 08:35

    MS Teams послала запрос в сеть, и пока ей доставят ответ - сидит и курит бамбук

    ^^THIS. Порочность aaS-ов


  1. NickDoom
    05.11.2024 08:35

    Да, виноват не конкретный фреймворк или технология, а системное, ради денег, «починяние того, что не сломано». Если строитель пытается через два года сжечь мой дом, чтобы впарить мне новый — я, вероятно, буду пытаться догнать его с дедушкиными вилами в руках, а не смирюсь с ситуацией.

    В айти почему-то сложилась противоположная картина, видимо, слишком быстро взлетели от землянок до небоскрёбов и не уловили тот момент, когда естественную смену подменили на искусственную.

    И это, опять же, не какие-то маркетологи — поветрие общее. Совсем недавно была статья на тему злых менеджеров, чинящих то, что не сломано — и посреди этой статьи наезд на Си с его страшлыми ужаслыми UB (автор явно не застал Си от слова «совсем», возможно, в силу юности или из-за раннего попадания в дурную среду). Я это даже словами не смог прокомментировать — просто прицепил известный мем, слова тут бессильны. Автору надо сказать большое спасибо, кстати! Хорошо продемонстрировал (на себе), как это бывает.


  1. Tamerlan666
    05.11.2024 08:35

    Спасибо за наводку на Zed. Надо действительно попробовать. Быстрота - это всегда приятно. В свою очередь могу поделиться наводкой на очень удобный и быстрый кросс-платформенный терминал-клиент WindTerm. Мне он понравился гораздо больше, чем остальные, включая iTerm2, Termius, Hyper и прочие.


    1. AndreiKud
      05.11.2024 08:35

      Пару месяцев назад он ещё был сыроват. Я так понимаю он сейчас в чем-то типа альфы. Сниппеты у меня не взлетели и баговался, когда пытаешься новый файл открыть из проводника, когда Zed уже запущен. Очень жду, когда чуть созреет, производительность реально впечатляет


    1. DrZlodberg
      05.11.2024 08:35

      Шило на мыло. Когда у тебя на компе работают современные игры, но не работает текстовый редактор(???) - это не то, что можно ожидать. ZED требует Вулкан (зачем он текстовому редактору?), с которым есть некоторые сложности на не самых свежих видеокартах.


      1. andreymal
        05.11.2024 08:35

        Вулкан (зачем он текстовому редактору?)

        Тут скорее интересен противоположный вопрос — зачем современному приложению использовать устаревшие API (или, о ужас, откатываться на программный рендеринг с потенциально большим жором процессора)

        Впрочем, Zed можно запустить на OpenGL, хотя пока что глючит


        1. DrZlodberg
          05.11.2024 08:35

          Эммм... Смысл АПИ в универсальности. И с каких пор оно устарело?

          Ну так без вуклана оно и работает на програмном, на сколько я понял. Где-то 3фпс.

          Текстовый редактор должен работать с текстом, а не заменять собой Adobe After Effects. Есть прекрасные и очень быстрые редакторы не требующие разогнанных 4060 для своей работы, Как-то справляются.


      1. VADemon
        05.11.2024 08:35

        Внезапно, старые виндовые API не очень-то отзывчиво ведут себя при 4K. Может MS в последнее время под капотом что-то да переписывали, но сближения с "большими" графическими API будет не избежать.


        1. DrZlodberg
          05.11.2024 08:35

          И по этому у меня на линуксе на gtx1060 в HD пустой текстовый редактор работает с 3 фпс. Мы точно туда свернули? Напоминает времена DOS, когда каждый таскал с собой дрова под всё железо и полностью реализовывал вообще всё, зачастую включая функции BIOS. Сначала все забили на единый интерфейс ОС, раскрашивая окошки под хохлому, тепер забили и на вообще всю отрисовку. Т.е. у нас теперь есть самодостаточный текстовый редактор и ОС только для телеметрии. Отличный план.

          ЗЫ: У меня нет 4к, но сильно сомневаюсь, что там проблема в нём.