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

Где мы свернули не туда? Как получилось, что современный десктопный GUI по умолчанию использует платформу HTML/CSS/JavaScript, которая изначально не предназначена для нативной работы на десктопе? Она создана конкретно для браузера и веба. Зачем из нативного софта делать веб-страницы в браузерной оболочке?

Джефф Этвуд (автор Stack Overflow) предсказал ^[1] этот феномен ещё в 2007 году. Он тогда сформулировал так называемый закон Этвуда:

Любое приложение, которое можно написать на JavaScript, будет в итоге написано на JavaScript.

Так и вышло.

А если серьёзно, то это явный тренд в софтверной разработке, который наблюдается уже два десятилетия. Сейчас большинство GUI-приложений разрабатываются на платформе HTML/CSS/JavaScript.

Для разработки кросс-браузерных приложений на веб-стеке чаще всего используется платформа Electron ^[2], которая стала своеобразным стандартом.

В наше время на «Электроне» сделано практически всё ^[3]:

• 1Password
• Asana
• Discord
• Figma
• GitHub Desktop
• Microsoft Teams
• Skype
• Slack
• Trello
• Twitch
• Visual Studio Code (на скриншоте вверху)
• WhatsApp

… и десятки других популярных десктопных программ.

Люди смирились и просто смотрят, как одна за другим нативные программы переходят на Electron со всеми вытекающими последствиями. Дело даже не в общей тормознутости и излишнем пожирании памяти (хотя это неизбежно в браузерной оболочке). В реальности производительность JS-кода по части UI даже обогнала типичный .NET за счёт многолетней тщательной оптимизации выполнения JS в браузерах. Нормально спроектированные JS-приложения сейчас гораздо быстрее, чем раньше. Но они по определению не могут сравниться с нативным софтом. Поэтому раздувание софта идёт полным ходом ^[4].

▍ Коммодитизация разработки

Почему так происходит? Логика абсолютно понятна. Фирме выгоднее разрабатывать и поддерживать одну платформу (веб) вместо N (веб+разные десктопные и мобильные ОС). Это чисто экономический вопрос: банально требуется меньше программистов.

Преимущества нативных приложений совершенно не очевидны для компании. Да, они могут быть быстрее. Но для этого нужно приложить усилия по оптимизации. И разница в скорости не так велика, чтобы обращать на неё внимание.

JavaScript проще, чем C++, так что и с этой точки зрения веб-платформа кажется привлекательнее. Происходит своеобразная коммодитизация разработки, когда создание приложений ставится на конвейер. Все они становятся похожи друг на друга, и производятся в «фабричном» стиле с помощью фреймворков типа Angular JS и Vue.JS. Правда, со временем становятся видны недостатки такого подхода ^[5]:

• несовместимость разных версий фреймворков (приходится частично переписывать код);
• браузеры, стандарты и экосистема HTML/CSS/JS слишком быстро изменяются (гораздо быстрее, чем это нужно для коммерческих приложений);
• трудности в поддержке.

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

▍ Лучший консольный софт

Программисты старой школы не поддаются на новые веяния. Если посмотреть на творения лучших разработчиков ^[6], то там код максимально оптимизирован, GUI зачастую отсутствует, а производительность — наивысший приоритет. Вот список крутых опенсорсных программ ^[7], которые выбиваются из общего ряда. Это принципиально другой, «антипотребительский» подход к разработке. К сожалению, таких образцов становится всё меньше. Последние могикане. Упомянем некоторые из них:

▍ Аудиоплееры

• moc ^[8] — консольный аудиоплеер для Linux/UNIX
• mpd ^[9] — клиент-серверный плеер с консольным и графическим интерфейсом
• mus ^[10] — модульный демон/клиент с консольным интерфейсом, который принимает плейлисты в текстовом виде
• vorbis-tools ^[11] — плеер Ogg/FLAC

▍ Торрент-клиенты

• btpd ^[12] (The BitTorrent Protocol Daemon) — торрент-клиент, реализованный в виде демона

▍ RSS-ридеры

• newsraft ^[13] — фид-ридер с интерфейсом ncurses ^[14]
• sfeed ^[15] — парсер RSS и Atom с интерфейсом sfeed_curses UI ^[16]
• snownews ^[17] — текстовый RSS-ридер для Linux и Unix
• zs ^[18] — Zeitungsschau, конвертер RSS/email

▍ Файл-менеджеры

• lf ^[19] — файл-менеджер в стиле ranger, написанный на Go
• mc ^[20] — Midnight Commander, кросс-платформенный классический файл-менеджер
• nnn ^[21] — Nnn's Not Noice, форк noice с большим количеством функций
• noice ^[22] — маленький и портативный файл-браузер
• ranger ^[23] — файл-менеджер с привязкой сочетаний клавиш на текстовый редактор vi, написанный на Python, с очень приятным интерфейсом
  

  ranger

• rover ^[24] — простой консольный файл-браузер
• sfm ^[25] (simple file manager) — простой файл-менеджер для unix-подобных систем

▍ Git

• stagit ^[26] — генератор статических HTML-страниц для репозитория git
• stagit-gopher ^[27] — генератор страниц в формате .gph (gopher)
• stagit-gemini ^[28] — генератор страниц в формате .gmi (gemtext) для Gemini.

▍ Вьюеры картинок

• feh ^[29] — продвинутый вьюер с функцией установки обоев для рабочего стола
• imv ^[30] — простой вьюер X11/Wayland, зависимости: SDL2 и FreeImage
• lel ^[31] — простой вьюер для X11, читает изображения в формате Farbfeld
• meh ^[32] — вьюер, который напрямую использует XLib, libjpeg, libpng and libgif
• qiv ^[33] — Quick Image Viewer
• sxiv ^[34] — simple/small/suckless X Image Viewer, зависимости: xlib и imlib2. В данный момент осиротел (нет мейнтейнера)
• nsxiv ^[35] — Neo Simple X Image Viewer, форк осиротевшего sxiv, зависимости: xlib и imlib2
• xli ^[36]
• xwallpaper ^[37] — минималистичная утилита для обоев рабочего стола
• xzgv ^[38]

▍ Медиаплееры

• ffplay ^[39] — простой и портативный медиаплеер, поставляется с ffmpeg, которому нужен для работы mplayer
• mplayer ^[40]
• mpv ^[41] — свободный, кросс-платформенный медиаплеер

▍ Уведомления

• herbe ^[42] — уведомления без демонов и D-Bus. Минималистичный, легковесный, написан на C. Для вызова можно использовать tiramisu ^[43]
• tiramisu ^[43] — демон уведомлений на базе dunst, который передаёт нотификации в STDOUT, так что пользователь может обрабатывать их на своё усмотрение, как в панели dwm

▍ Парольные менеджеры

• oathtool ^[44] — Open AuTHentication (OATH) для одноразовых паролей
• pinentry-dmenu ^[45] — программа для ввода паролей pinentry с добавлением динамических менюшек dmenu ^[46]. Подходящий интерфейс для pass ^[47]
• pass ^[47] — «стандартный парольный менеджер UNIX»
• spm ^[48] (simple password manager) — активно поддерживаемый форк tpm
• tpm ^[49] (tiny password manager)

▍ PDF-вьюеры

• mupdf ^[50] — легковесный PDF-вьюер, написанный на C. Поддерживает PDF, XPS, EPUB, XHTML, CBZ, PNG, JPEG, GIF и TIFF
• zathura ^[51] — расширяемый вьюер/оболочка, поддерживает CBZ, DJVU, PS, EPUB (с mupdf) и PDF (с mupdf или poppler)

▍ Оболочки

• dash ^[52] — POSIX-совместимая реализация /bin/sh, оптимизированная на минимально возможный размер
• mksh ^[53] (MirBSD Korn Shell) — активно разрабатываемая свободная реализация языка программирования оболочки Korn Shell, наследник Public Domain Korn Shell (pdksh)
• oksh ^[54] — портативная версия ksh из OpenBSD
• yash ^[55] (yet another shell) — задуман как POSIX-совместимая оболочка, которая в то же время поддерживает функции для ежедневного интерактивного и скриптового использования

▍ Текстовые редакторы

• acme ^[56] — текстовый редактор Роба Пайка для Plan 9. Включён в состав plan9port ^[57]
• ed ^[58] — «стандартный текстовый редактор» ^[59]
• ired ^[60] — минималистичный hex-редактор и биндиффер для p9, w32 и *nix
• mg ^[61] — портативная версия mg, поддерживается командой OpenBSD
• mle ^[62] — маленький, гибкий консольный текстовый редактор
• nano ^[63] — клон pico, маленький и простой в использовании
• neatvi ^[64] — минималистичная реализация vi с поддержкой двунаправленного UTF-8 (LTR/RTL)
• nextvi ^[65] — продолжение разработки neatvi с дополнительными функциями
• nvi ^[66] — маленький редактор в стиле vi
• micro ^[67] — консольный текстовый редактор со стандартными сочетаниями клавиш типа ctrl-c/v
• sam ^[68] — редактор от Роба Пайка, написанный под вдохновением от ed
• sim ^[69] — текстовый редактор на основе vim и sam
• traditional vi ^[70] — исправленная версия оригинального vi
• vim ^[71] (в GUI рекомендуется :set go+=c для блокировки всех всплывающих окон) может быть скомпилирован в предельно минималистичном стиле, как vim-tiny в репозиториях Debian
• vis ^[72] — современный и эффективный редактор в стиле vim
• wily ^[73] — клон acme для POSIX

▍ Обработка текста

• csvquote ^[74] — инструмент для кодирования проблемных символов CSV, чтобы unix-инструменты могли корректно их обрабатывать. Оптимизация SIMD по умолчанию, при сборке можно активировать откат на портативную версию C
• json2tsv ^[75] — конвертер из JSON в TAB-Separated Value (TSV) и отдельный JSON-парсер
• md4c ^[76] — конвертер из Markdown в HTML, быстрый, совместимый с CommonMark ^[77], поддерживает расширения, которые можно включать/отключать из консоли

▍ Утилиты/другое

• abduco ^[78] — подключение/отключение сессий
• dvtm ^[79] — динамический менеджер виртуальных терминалов
• entr ^[80] — запуск произвольных команд по факту изменения файлов
• mrandr ^[81] — простой и легковесный менеджер профилей мониторов (дисплеев), написанный на языке POSIX Shell
• mtm ^[82] (Micro Terminal Multiplexer) — мультиплексор консолей, на скриншоте внизу три инстанса tine ^[83]
  

• nq ^[84] — утилита очереди командной строки UNIX
• pv ^[85] — инструмент для мониторинга прохождения данных по конвейеру
• smenu ^[86] — мощный и универсальный инструмент выделения в консоли для использования в интерактивном режиме или в скриптах
• snore ^[87] — пауза с визуальным фидбеком
• yt-dlp ^[88] — форк youtube-dl для скачивания видео и звука с YouTube и других платформ
• zbar ^[89] — пакет для распознавания штрихкодов из разных источников (видео, фото)

Полный список см. на сайте Stuff That Rocks ^[7].

▍ Оптимизация приложений. Примеры

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

Люди очень чувствительны к задержке интерфейса. Пятнадцать лет назад Amazon выяснила ^[90], что каждые 100 мс задержки веб-сайта уменьшают продажи на 1%. С тех пор требования публики значительно ужесточились.

В 2017 году Akamai констатировала, что каждые 100 мс задержки снижают конверсию уже на 7% ^[91].

В 2018 году Google опубликовала статистику ^[92] по загрузке мобильных страниц. Выяснилось, что пользователи на мобильных устройствах менее терпимы к задержкам. Так, при росте задержки с одной до трёх секунд количество отказов от загрузки возрастает на 32%, при росте до пяти секунд количество отказов увеличивается на 90%, и так далее.

• Рост задержки с 1 до 3 с → количество отказов возрастает на 32%
• … с 1 до 5 с → на 90%
• … до 6 с → на 106%
• … до 10 с → на 123%

Поэтому так важно оптимизировать мобильные сайты и приложения. И есть стандартные способы оптимизации, доступные каждому. Например, разработчики DoorDash рассказали ^[93], как ускорили первоначальную загрузку iOS-приложения на 60%:

1. Профилирование для выявления узких мест (они использовали Xcode, а также Performance Analysis ^[94] от Emerge Tools).
   

   Трассировка стека, показывающая три возможности оптимизации

2. Исправление трёх основных проблем, на которые тратится время в основном потоке:
   • Проверка соответствия протоколу Swift ^[95] — никто даже не знал, что стандартный String(describing:) ^[96] занимается такими дорогими операциями.
     

     Трассировка стека String(describing:) API

     Замена идентификации типов String(describing:) на простой указатель типа ObjectIdentifier сразу ускорила загрузку приложения на 11%, а это всего одна строчка кода!

     

   • Отказ от тотального хеширования AnyHashable ^[97] абсолютно всех действий и команд для хранения их уникальных значений. Переосмысление архитектуры привело к пониманию, что необязательно идентифицировать все команды по их хешу, а зачастую достаточно просто указателя на тип.
     

     Эта простая оптимизация (опять одна строчка кода) ускорила запуск приложения ещё на 29%, а выполнение команд — на 55%.

   • Аудит инициализации сторонних фреймворков показал, что эти ненужные вызовы замедляют запуск приложения примерно на 200 мс (конкретно в этом случае виноват фреймворк ServiceCore от Salesforce).
     

     Разработчики подкрутили динамический линкер (dyld), чтобы он пропускал эти вызовы при запуске.

Все сделанные оптимизации в целом ускорили запуск приложения DoorDash примерно на 60%.

Эта история наталкивает на мысль, что большинство мобильных приложений абсолютно не оптимизированы. Они включают в код внешние библиотеки, которые 90% времени выполняют ненужные операции, как String(describing:) ^[96] выше, добавляя задержку на пустом месте.

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

Есть мнение, что пользователям не нужен быстрый софт, потому что они якобы «ленивы и туповаты» ^[98]. Мол, пипл «схавает» всё, что дадут. Даже ужасной прилагой с задержкой десять секунд на каждое нажатие будет кто-то пользоваться. Люди привыкают к ужасу — и начинают считать его нормой. Однако адаптивный механизм психики — не оправдание для создания плохих продуктов.

Так или иначе, но фронтенд на HTML/CSS/JavaScript стал стандартом на всех платформах: и на десктопных, и на мобильных. Даже инструменты для разработчиков выпускаются в том же стиле. Например, Visual Studio Code ^[99] на КДПВ — это браузер (Chromium) с сервером Node.js и файлами HTML/CSS, скомпилированными в исполняемый бинарник. Все переходят на веб-платформу. Ничего не поделаешь, таков путь.