В чём смысл делать приложения-прокладки?

Question

[WSGlebKavash]

Пытался установить "ВК Мессенджер" на Ubuntu Sway Remix. Он требовал pulseaudio, но в системе был только PipeWire. Но это не важно.
Решил я в итоге поковырять приложение. И я обнаружил там Chromium. Более того, в самой программе есть DevTools. То есть, мы имеем просто сайт, обёрнутый в приложение.
Зачем нужны такие программы? В чём смысл такой разработки?

Comments

[mayton2019]

Это нормально. Это в принципе ничем не отличается от повторного использования библиотек
в своем софте. В данном случае хромиум сыграл роль такой повторяемой библиотеки.

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

Answer 1

[Василий Банников]

Пользователь хочет приложение в отдельном окне и с ярлыком на рабочем столе.
Разработчики не хотят тратить ресурсы на его разработку.
Вот и заворачивают веб приложение в пакет.

Answer 2

[Everything_is_bad]

Зачем нужны такие программы? В чём смысл такой разработки?

но ты его минимум захотел установить, у тебя были альтернативы?

Answer 3

[Сергей]

Более быстрая "нативная" разработка. У вас уже есть готовый фронт, который компилуется в приложение.

Answer 4

[ImagineTables]

Смысл для КОГО?

Для вас, как для пользователя, смысл в том, что «сайт» будет хорошо заизолирован. Никаких межсайтовых кук, никакой проверки истории посещений через

body:has(a[href="pornhub.com"]:visited) .mychecker
{
    backgound-image: url(drochit.png);
}

и т.д. Правда, толку от этого немного, но всё равно приятно. (Если, конечно, основной рабочий браузер держать в нестандартном месте, чтобы напрямую там никто не ковырялся).

Для разработчиков смысл в том, что:

1. Фиксируется набор фич и багов, при изменении в будущих версиях браузера всё гарантированно будет работать без необходимости постоянно тестировать и подправлять клиентский код. (Уж как я ни стараюсь делать всё по стандартам, а через пару лет обновлений браузера то одно отвалится, то другое).
2. Ресурсы можно плавно раскатывать по юзерам вместе с приложением, от сервера останется только API. Что удобно в организационном плане.
3. Всё грузится мгновенно. Не только не надо больше думать про прекэширование, загрузочные оптимизации, но и вообще беспокоиться о размере картинок/аудио/видео/шрифтов/файлов с лицензиями и пр.
4. В своей сборке браузера можно перенастроить политики т.н. «безопасности». Которые нужны, по сути, только чтобы не дать помешать впариванию рекламы.
5. В свою сборку браузера можно включить любые аддоны. (Если есть готовый аддон с нужным функционалом, может оказаться проще использовать его as is).
6. Главное — вы уверены, что видели весь код? Иногда надо сделать фичу-другую, которые имплементируются ТОЛЬКО через вызов OS API. А без них это будет приложение хуже классом.

Answer 5

[Артём Дайнов]

Потому что пользователю нужно приложение.
Он так будет считать, что если есть приложение, значит этому проекту можно доверять.

Answer 6

[Komrus]

А менеджерам проекта - нужна аналитика, статистика и сбор данных. Что удобнее делать в своём приложении. Увы, как бы не было это печально, но таковы нонешние реалии...

Answer 7

[CityCat4]

В отрицательной эволюции тырнета. Пользователю хочется десктопное приложение. Разрабу не хочется писать гуй. Потом все хором жалуются на то, что комп тормозит. А фигли ему не тормозить, когда у него на самом деле не браузер параллельно киенту запущен, а два бразуера?

Answer 8

[Пума Тайланд]

Ну как бы сделать такое приложение пол часа, в обед время вообще каждое второе приложение на Андроиде было таким, когда Гугл сделал возможность запускаю хтмл приложения на Андроиде и всем казалось вот оно