Pull to refresh
2675.55
RUVDS.com
VDS/VPS-хостинг. Скидка 15% по коду HABR15

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

Level of difficultyMedium
Reading time8 min
Views35K

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

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

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

Так и вышло.

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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


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

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


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

▍ RSS-ридеры


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

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


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

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

▍ Git


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

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


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

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


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

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


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

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


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

▍ PDF-вьюеры


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

▍ Оболочки


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

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


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

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


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

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


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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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


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

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

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️
Tags:
Hubs:
+79
Comments261

Articles

Information

Website
ruvds.com
Registered
Founded
Employees
11–30 employees
Location
Россия
Representative
ruvds