усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Десктопные UI
усы2
tonsky

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

Кажется, что идея провальна с самого начала. Но в мире есть успешный пример кросс-платформенных UI которые прилично выглядят на любой платформе. Это веб. Да, веб-сайты не собраны из системных компонентов, каждый вебмастер рисует свои кнопки и панели с нуля. Но все привыкли и не возражают. Браузер аккуратно доделывает системно-специфичные детали: нативный скролл (с инерцией или без), рендеринг и выделение текста, системные контекстные меню, системное поведение внутри даже полностью перерисованных инпутов. Системные нюансы, даже в комбинации с полностью уникальным скином и лайаутом, создают вполне приятный пользовательский опыт. Решение оказалось в том, чтобы не притворяться нативным системным приложением, иначе попадешь в uncanny valley, область фальшивых елочных игрушек.


на фото: Transmission Remote GUI (Free Pascal) притворяется нативчиком

На основе браузера сделали Электрон — бандл из хрома, node.js и ваших html/css/js, упакованных в обертку как-бы-приложения. С точки зрения пользователя — всё классно. VS Code, Atom, LightTable, Figma, Zeplin, Slack, VK Messenger, Rocket.Chat, Github Desktop, GitKraken, Basecamp, Ghost, Brave browser, Hyper, SimpleNote — прекрасные, вылизанные приложения, очевидно, что как платформа Электрон уже состоялся.


на фото: системное контекстное меню в Visual Studio Code (Electron)

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

Претензия к Электрону, собственно, одна — это такой Докер для десктопа. То есть он пакует огромную тучу всякой фигни ради несоизмеримо маленького функционала. То, что нужно Хрому для веба, например совместимость с IE 5.5, всякие quirks mode, не знаю, видеокодеки, non-strict JS, устаревшие CSS свойства и режимы и совместимость их с новым и современным — это раз в 100 больше того, что вы когда-либо сможете и захотите использовать. И это никак не отковыряешь. Меня даже не размер бандла беспокоит, а то что весь этот легаси серьезно мешает приложению достичь своего потенциала скорости, простоты, надежности. Тот же JS — явно не лучший язык, с кучей совершенно левых/произвольных проблем-ограничений, медленный просто потому, что он настолько плох что уже не ускоряется, явно не готовый к тому, что под ним будет файловая система, что бывают потоки — да, мы не можем выкинуть его в вебе — но на десктопе-то ради чего страдать?

К сожалению, с браузером только всё-или-ничего. Как и докер, это явно неверный вектор развития — бандлить кучу говна просто потому, что так получилось и проще. И все равно web это лучшая на сегодня UI платформа, с лучшим integrated developer experience.

Вопрос, собственно, про альтернативы. На случай, если я проглядел что-то.

На QT бывают хорошие, красивые приложения. QT бывает кросс-платформенный, но это C++. Он, конечно, обходит JS по категории sanity, потому что он не сильно умный и в любой ситуации ты просто делаешь то что тебе нужно, а не пытаешься бороться с тормозами вмененного тебе динамизма. Figma, например, компиляют C++ в JS, чтобы работать в вебе, но лишь бы не писать на JS. Но все равно C++ ужасный язык, низкоуровневый, долгая компиляция, без REPL-а — а UI работу я себе не представляю без REPL-а.


на фото: Telegram Desktop (QT5) с кастомным контекстным меню. Не видно, но скролл тоже фальшивит

Java-решения (Swing/JavaFX) страшны как черт. Я тут скачал демку JavaFX, которая прям с дистрибутивом идет, так у них даже ховер на кнопках тормозит. Плюс естественно всё не нативное — ни скролл, ни выделения, ни контекстные меню, а нарисованное как будто программистами. Окей чтобы накидать что-то по-быстрому для нетребовательной аудитории клерков, но вылизать, кажется, невозможно.


на фото: Modena demo app (JavaFX). Пойдет, но тормозит и всё ненастоящее

Я не уверен, насколько хорош в этом плане SWT — смогу ли я выкинуть весь look-and-feel и нарисовать что-то стильно-современно-плоское, например? Не хотелось бы, чтобы получилось что-то уродливое вроде Eclipse. Он вообще живой еще?


на фото: страница проекта SWT

Что еще бывает? Или выхода нет?

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


  • 1
Так в самом же посте содержится и ответ. Бери Electron и вылизывай UI. Ну бандлит он что-то, ну и что? Главное же скорость разработки.

Берешь React и React Native и покрываешь:
Web, Windows, Linux, MacOS, Android, iOS, и горя не знаешь.

А со всякими Java или не дай бог C++ горя не оберешься.

Меня бесит корявость web-платформы и странности JS

Ну остальное-то еще хуже ведь. Тут меньшее из зол выбирать приходится.

И что ты кстати против Докера имеешь? До него же вообще ад был.

То что он бандлит кучу ненужного говна ради одного дохленького процесса. Берем интерактивную многопользовательскую систему и запускаем на ней не-интерактивный единственный процесс. Разработчики языков срут зависимостями куда попало и как попало. Вместо того чтобы со всем этим адом _разобраться_, давайте на каждый чих создавать целую вселенную и пусть они внутри там хоть усрутся. Это не наведение порядка. Это создание условий для более удобного разведения ада.

Это путь задом наперед. Правильный путь — делать все нормально и аккуратно, строить только то что нужно, а что ненужно не строить. Java-программисты, например, до сих пор не понимают, зачем докер. У них и так всё норм, четко, предсказуемо и изолировано. В еще более общем случае решение — unikernel.

Ну мы же живем не в стране эльфов. Разработчики будут делать все так, как им удобно и идти по пути наименьшего геморроя. Это нужно воспринимать как данность, как аксиому человеческой природы. А про то, что все всё будут делать правильно - это мечта о молочных реках.

А Докер решает эту проблему. Он дает удобство и изоляцию. И заводится с полоборота. Я, к примеру, недавно пытался OpenCV поставить на Ubuntu, а там адовые зависимости, да еще и на сайте ужасные доки как будто из 90-х, которые только бородатые оленосвитероносы разве что могут читать. Так и не смог завести нормально. А в docker'e написал from ***opencv и полетел. Ну и что, что он там что-то лишнее докачивает. Жесткий диск стоит копейки, а время разработчика стоит килобаксы.

Ты зря Java программистов обижаешь.

Они тоже Docker умеют (Spring Boot -> Docker -> ECS/Kubernetes -> щастье).

Потому что а как иначе-то? Docker -- это как unikernel для бедных же.

> Потому что а как иначе-то

Эээм JAR? Я не обижаю, я хвалю

А дальше что с этим JAR делать? В серверах приложений крутить, что-ли?

Про чётко, предсказуемо и изолировано забавно, что ниже ты сам приводишь в пример развёртывание сервиса через java -jar.

Внутрь JAR ты, наверное, и веб сервер положил (Jetty какой-нибудь) и все зависимости.

Вот считай, что системные библиотеки -- это и есть такие же зависимости для нативных приложений.

Ну да, но расчет такой что в jar попадают только библиотеки, которые непосредственно нужны для выполняемой задачи, и не попадает всё остальное. Хотя JVM тоже тот еще докер сама по себе, конечно.

Ну написали же они как то этот ваш LT на Cljs. Или можно Typescript - безболезненно, и он не такой страшный как JS

Да не, компилять в JS не вопрос. Проблема в том, что компилять придется именно в JS :( А он хреновый compilation target

Если будет нехватка производительности на electron, то есть надежда что можно будет использовать webasm или webgl для расчетов. Например писать на чистом Rust а он сам будет что-то кидать в js, что-то в webasm, что то в webgl.

это не надежда, это страшный сон. Хотя, вон Figma компиляют Emscripten и рисуют всё сами

(Анонимно)
Вот только после того как ты взял и покрыл, оказывается что например на Андроид надо написать еще миллион нативных плагинов, и все равно все работает через одно место. И в результате получается что лучше бы сразу все написали на нативе и не ввязывались в эти танцы с бубнами.

  • 1
?

Log in

No account? Create an account