Что лучше web или desktop
Перейти к содержимому

Что лучше web или desktop

  • автор:

Десктопное или веб-приложение: плюсы и минусы

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

Итак, веб-приложение работает через браузер, используя его как среду выполнения, десктопное— устанавливается, запускается и работает локально. Сравним их по основным характеристикам.

Установка, обновление

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

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

Публикация / развертывание

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

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

Надежность

Работа веб-приложения зависит не только от того, насколько грамотно оно разработано и характеристик пользовательского устройства, но также от скорости интернет-соединения, работоспособности удаленного сервера.

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

Доступность

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

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

Кроссплатформенность

Веб-приложение одинаково хорошо будет работать на любом устройстве, будь то стационарный компьютер, ноутбук, планшет или смартфон — ведь оно практически не зависит от «железа» или операционной системы. Главное — подходящий браузер. Как правило, для работы большинства веб-клиентов подходят Google Chrome, Mozilla Firefox, Safari от Apple или Windows-браузер (Microsoft Edge / Internet Explorer).

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

Функциональность, быстродействие

Веб-приложение полностью зависит от браузера и технологий его работы. Поэтому есть ряд ограничений, например — в доступе к аппаратному обеспечению вашего устройства. Это и некоторые другие ограничения обойти невозможно (во всяком случае, сейчас). Но целый ряд задач можно решить по принципу «что нельзя переписать, можно надстраивать или расширять». Редакторы документов, изображений, аудио, видео, 3D графики; системы управления проектами; хранилища файлов; no-code конструкторы — успешно работают в браузерах. Инструменты быстрой интеграции сервисов, а также интерфейсные библиотеки еще больше расширяют существующие возможности.

Десктопное позволяет реализовать буквально любые функции — в этом оно однозначно превосходит web. Во всяком случае, полноценного онлайн аналога Photoshop или Sony Vegas еще никто не разработал. Системные утилиты — определенно сфера десктопной разработки. Как и программы, которые должны долго работать в фоновом режиме — например, чаты или торрент-клиенты — через браузер с ними просто неудобно будет работать. Также такое ПО чаще используется для специфических проектов, с нестандартными интерфейсами или функциями. Поэтому web разработка пока не представляет опасности для desktop программистов— эти технологии будут развиваться параллельно, просто под разные задачи.

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

Безопасность

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

Десктопное настраивается более гибко, а значит — теоретически при его разработке можно предусмотреть все потенциальные уязвимости. На практике — вряд ли. Впрочем, сделать его полностью безопасным все же можно. Но только если устройство, на котором оно установлено, не будет никуда подключаться, даже к защищенной локальной сети. В противном случае — риск все равно будет.

Однозначно сказать, что безопаснее — сложно (если вообще возможно). На это влияют много факторов, прежде всего — человеческий. А ведь именно в защите от человеческого фактора, в различных его проявлениях, заключается смысл всех мер безопасности.

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

Наши выводы

Возможности браузерной разработки огромны, ее потенциал раскрыт далеко не полностью. Технологии развиваются, рынок ИТ растет, предлагая все новые приложения — при прочих равных пользователи будут выбирать web просто потому, что это удобнее. Если говорить о решениях для корпоративных клиентов, то тут браузерные приложения незаменимы. Они гибкие, универсальные, не требуют предварительной подготовки среды, позволяют сэкономить финансы компании, аппаратные ресурсы, время сотрудников.

Альтернативное мнение

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

Веб-приложения уже сейчас подходят для решения многих задач — как бизнеса, так и обычных пользователей. Если вы решили разработать свое — используйте no-code платформу AppMaster.io.

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

Какое бизнес-приложение нужно вашей компании: web или desktop?

web-or-desktop

Идея написать статью на эту тему возникла в 2020 году, когда к нам с запросом на разработку ПО обратился крупный региональный производитель профлиста. Компании понадобилось приложение для менеджмента заказов на производство и доставку, и уже был определен примерный список требований.

Одним из пожеланий заказчика была разработка именно десктоп-приложения. Однако в процессе обследования и оценки задач мы вместе с клиентом пришли к выводу, что быстрее разработать web-приложение на платформе Jmix (ранее Cuba Platform).

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

web-or-desktop

Важно! Так как статья ориентирована на читателей, которые знакомы с IT-сферой и разработкой ПО скорее на уровне пользователей, чем на уровне системных администраторов, для начала определим предмет разговора и уточним, что мы понимаем под вебом и под десктопом.

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

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

Это поверхностная разница на уровне очевидных для пользователя моментов, хотя на самом деле отличий у этих двух типов приложений гораздо больше.

Мифы о десктоп-приложениях

Еще 10-15 лет назад на рынке программного обеспечения царствовали именно десктоп-приложения, а веб только-только начинал развиваться. Процесс массового перехода к вебу происходил постепенно, и вот уже мы открываем большую часть необходимых для работы программ именно в браузере. Но, тем не менее, в представлении многих пользователей именно десктоп остался символом надежности, быстродействия и простоты. Так ли это на самом деле? Рассмотрим и попробуем опровергнуть самые распространенные мифы.

Миф №1 «Десктоп всегда безопаснее, а из веб-приложения нашу информацию могут украсть»

И да, и нет. Если сервер находится «снаружи» организации, и доступ к нему недостаточно защищен, то данные могут украсть независимо от того, будете ли вы пользоваться десктоп или веб приложением. То есть тут мы путаем «технологию разработки» и собственно архитектуру системы, и то, как организована защита передачи данных. Первично именно то, где находится сервер, насколько он защищен, и насколько защищены каналы доступа с клиентских ПК до сервера.

Технология разработки и интерфейс – этот как раз или веб-клиент, или десктоп. Это та часть, через которую пользователь взаимодействует с программой и запускает какие-то процессы. Защитить информацию на этом уровне можно только путем настройки доступа: создать надежные пароли и организовать их безопасное хранение, настроить уровни прав доступа для разных групп пользователей, установить на ПК антивирусы, которые обнаружат вредоносное и шпионское ПО.

Но самое ценное – собственно коммерческая информация, например, список клиентов и договоров – находится в базе данных. Местом ее хранения может быть:

  • собственный физический сервер, который стоит в вашем офисе;
  • арендованный сервер, который физически находится в ЦХОДе (центре хранения и обработки данных) и доступен удаленно;
  • публичное облачное хранилище, арендованное по подписке.

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

Или если облачный сервер защищен от доступа посторонних, но пользователи получают доступ к данным через открытые каналы интернет без использования шифрования (VPN) – ваши данные под угрозой в любом случае.

Миф №2 «Десктоп работает и без интернета, а веб-приложение важна высокая скорость соединения»

Возможно, 10 лет назад это утверждение еще можно было назвать правдивым, но сегодня оно точно перешло в разряд мифов, и вот почему. Как веб, так и десктоп приложению для корректной работы может требоваться интернет, если:

  • для реализации какого-то сценария приложению нужно обязательно отправить запрос к стороннему серверу, доступному только через интернет;
  • само приложение и база данных находятся в облаке.

Пример: вам нужно простое десктоп-приложение для ведения сделок и хранения базы клиентов, которое будет работать на собственном сервере в офисе. Для удобства менеджеров в приложение встроена проверка потенциального контрагента по ИНН с указанием возможных рисков.

Для проверки система обращается к открытым источникам в интернете. Если в офисе отключили интернет, менеджеры смогут спокойно работать с самим приложением. Однако автоматическая проверка по ИНН не будет работать до того момента, пока не восстановится соединение.

Если в аналогичном примере у компании не один, а два офиса, а сервер вынесен за пределы офисной сети и доступен только удаленно, при отключении интернета любое приложение будет недоступно.

Миф №3 «Десктопные приложения проще и понятнее, чем веб»

Такое впечатление может сложиться после сравнения какой-то простейшей десктоп-программы, разработанной под конкретную задачу, и сложной многофункциональной веб-системы, такой как Битрикс24. И здесь мы снова сталкиваемся с тем, что выбор технологии разработки не влияет сам по себе на удобство интерфейса. Одинаково непонятную или наоборот удобную для пользователя систему можно построить как в виде «настольного» приложения, так и в его веб-версии.

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

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

Плюсы и минусы десктоп-приложений

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

Преимущества десктопных бизнес-приложений

    1. Более отзывчивые и быстрые при работе с высококачественной графикой и выполнении других операций, которые требуют большого количества ресурсов. Примеры: Adobe Photoshop, AutoCAD, Visual Studio. Да, для таких приложений выпускают облегченные веб-версии, но пока возможностей браузера недостаточно для полноценной замены более мощного десктопа.
      1. Лучше подходят для задач, которые подразумевают большое количество операций с файлами на рабочем месте пользователя. Ни одно веб-приложение без ведома пользователя не может пользоваться ресурсами его компьютера, например, текстовыми файлами. Если требуется автоматически забирать файлы и выполнять с ними какие-то действия (например, формировать отчеты), то стоит рассматривать именно десктоп.
      1. Подходят для работы с внешним оборудованием и программирования на аппаратном уровне.

      Возможные «минусы» выбора десктоп-приложений для бизнеса

        1. Разработка может занять больше времени и стоить дороже, чем в случае с вебом. Нельзя сказать, что это аксиома, так как можно использовать средства ускорения разработки с конструкторами экранов и других модулей. Другой вопрос, что этих средств становится все меньше и меньше, а стоимость их использования все выше. Раньше можно было использовать Delphi, Sybase PowerBuilder и другие системы, которые позволяли достаточно легко и просто создавать базу данных и интерфейс быстрее, и с минимальным по тем временам количеством кода. Такие системы есть и сейчас, но большая часть из них почти «мертва» либо стоит очень дорого. В то время как современные средства быстрого создания бизнес-приложений в вебе опережают их по функционалу и скорости разработки.
          1. Менее гибкое, дорогая разработка для кросс-платформ. Если у приложения должен быть сразу и десктоп, и веб-клиент, то стоимость разработки будет в несколько раз выше. Систем, которые позволяют делать это достаточно быстро, тоже становится все меньше, а стоимость лицензий на их использование может составлять несколько тысяч долларов в год на одного разработчика. Естественно, себестоимость средств разработки в итоге отражается на «счете» для заказчика. Например, если мы разрабатываем десктоп-приложение, которое должно одинаково выглядеть и корректно работать на Windows, Linux и MacOS, его стоимость будет минимум в 2-3 раза дороже, чем аналогичного приложения только для Windows. Конечно, есть средства разработки, позволяющие разработать относительно универсальный клиент, но даже при их использовании понадобятся дополнительные доработки, например, экранных компонентов для Linux.
          1. Сложные и дорогие в поддержке. Если сравнивать процесс обновления десктоп и веб-приложения, второй скорее всего будет быстрее и проще. Для обновления десктопа понадобится сначала обновить сервер, а затем версию программы на машинах всех пользователей. В зависимости от количества ПК и сложности процесса это может занять от нескольких часов до нескольких дней. Поэтому при заказе разработки десктоп-приложений нужно быть к таким временным затратам вашего системного администратора.

          Веб-приложения: преимущества и недостатки

          Преимущества

          Гибкие и кросс-платформенные решения, дешевле разработка

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

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

          Но не стоит думать, что при заказе бизнес-приложения для компании на 15-20 пользователей этот пункт не важен. Даже если сейчас вам известно, на каких именно устройствах и платформах будет использоваться разработанное решение, уже через 1-2 года ситуация может измениться.

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

          Благодаря тому, что приложение было разработано на платформе Jmix, нам удалось успешно запустить программу даже на такой «древней» операционке. Если бы вместо веб-приложения мы разработали десктоп, то заказчику было бы проще купить новые ПК, чем дорабатывать приложение под Windows 7 ради нескольких рабочих мест.

          Проще в установке и поддержке

          Выше мы уже описывали процесс обновления версии десктоп-приложения. А теперь сравните с вебом: достаточно за 5-10 минут загрузить обновления на сервер и попросить пользователей «перелогиниться» в системе. Даже если в компании более 50-80 пользователей, провести обновление будет намного проще, чем в случае с десктопом.

          Недостатки веб-приложений для бизнеса

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

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

              Десктоп или веб: какое приложение подойдет для решения ваших бизнес-задач?

              Разработку десктоп-приложения стоит выбрать, когда вашей компании необходима программа для:

              • работы с высококачественной графикой и выполнения ресурсоемких задач, которые пока не под силу веб-приложениям;
              • управления внешним оборудованием;
              • работы с большим количеством файлов на ПК пользователя в автоматическом режиме;
              • совместной работы с уже существующим десктоп-приложением (например, дополнительный модуль для реализации дополнительных функций).

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

              Почему веб победил десктоп, но не победил мобильные?

              Чтобы ответить на подобный вопрос, может понадобится десяток лет исследований.

              Если мы сможем частично распутать этот узел, то, возможно, нам удастся перезапустить веб, создав новую платформу. Или начать создавать новые системы, похожие на веб.

              Я работал над пятью браузерами и одной операционной системой, наблюдая за тем, как этот вопрос оказывается связанным с UX, продуктом, стратегиями и разработкой. Не могу сказать, что у меня есть все ответы, но кажется, мне удалось распутать несколько важных нитей.

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

              Чего? Ниже представлено более подробное объяснение.

              Первая катастрофа

              Три миллиарда лет назад в атмосфере Земли не было кислорода. Солнце светило сверху на небо из CO2 и N2 — веществ, извергаемых вулканами. Однако Земля изобиловала жизнью. Одноклеточные анаэробные организмы процветали в почве и в неглубоких морях, впитывая тепло из гидротермальных источников.

              Затем однажды, 2,45 миллиарда лет назад, синезелёная водоросль научилась «есть» солнечный свет.

              Водоросль фотосинтезировала углеводы из CO2 и воды, выбрасывая в качестве продукта жизнедеятельности кислород. Солнечного света, CO2 и воды было много, а конкуренция отсутствовала. Водоросль начала размножаться.

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

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

              Оно называется кислородной катастрофой. Это явление проложило дорогу многоклеточным организмам (то есть нам).

              Все крушения похожи, но каждое из них сокрушительно по-своему

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

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

              Синезелёные водоросли выиграли, не конкурируя симметрично с анаэробами. Они выиграли благодаря тому, что не конкурировали. Фотосинтез был асимметричной стратегией выживания. Больше никто его не освоил. Рынок солнечного света был пуст. Результатом стала быстрая катастрофа.

              Мы наблюдаем похожие катастрофы и на протяжении истории технологий. Теоретик бизнеса Клейтон Кристенсен разработал для их объяснения теорию подрывных инноваций. Её источники, как и у кислородной катастрофы, лежат в асимметрии.

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

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

              Подрывные инновации совершают переворот в структуре конкуренции. Атмосферы меняются. Успешные компании задыхаются. Появляются новые компании. Технологии оказываются утерянными. Экосистемы уничтожаются. Сети создания стоимости распадаются и переформируются.

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

              Выживание в условиях подрывных инноваций тоже продиктовано обстоятельствами. Признаки, эволюционировавшие из-за не связанных с ними причин, внезапно оказываются важными для выживания. Маленький анаэроб, случайно эволюционно получивший толерантность к кислороду до появления синезелёной водоросли. Поисковый движок, купивший конкурента Symbian под названием Android до выпуска iPhone.

              Компьютерные эпохи

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

              Взглянув на историю компьютеров, мы можем выделить несколько эпох, порождённых подрывными инновациями. Взяв список технологических эпох Бена Томпсона и продлив его до самого начала, мы получим:

              • Эпоху зарождения: компьютеры для науки и войн
              • Эпоха мейнфреймов: компьютеры для бизнеса
              • Эпоха PC: персональные компьютеры для дома и школы
              • Эпоха веба: компьютеры, объединённые в сеть
              • Эпоха мобильных: компьютеры, которые всегда с тобой

              Так почему же веб подорвал десктопные системы, но не мобильные? Это вопрос о двух подрывных технологиях:

              • Почему веб подорвал десктопы? (Персональные компьютеры → сетевые компьютеры)
              • Почему веб не подорвал мобильные? (Сетевые компьютеры → компьютеры, которые всегда с тобой)

              Почему веб подорвал десктопы?

              Можно рассматривать веб как операционную систему внутри операционной системы. Веб начинался не с этого — поначалу он использовался только для обмена документами — но веб мог эволюционировать.

              Сочетание JavaScript, динамических серверов и XMLHTTPRequest позволило разработчикам создавать веб-сайты, которые отдалённо начали напоминать приложения. Это не были хорошие приложения, они имели ограниченные возможности.

              Однако веб обладал критически важной асимметрией: он был спроектирован для сети. Сеть всё изменила.

              Игра из однопользовательской стала многопользовательской. Приложения для PC по большей мере были однопользовательскими. Веб-приложения работали как общее ПО на сервере. Они по своей природе были многопользовательскими. Связь людей создаёт мощные психологические и сетевые эффекты. Мы социальные животные. Каждый процесс с более чем одним игроком становится процессом взаимодействия этих игроков.

              Ссылки сделали распространение ПО виральным. Чтобы купить новое приложение для PC, обычно нужно было поехать в магазин и приобрести коробку с CD. Чаще всего Интернет-подключения были слишком медленными для скачивания крупных многомегабайтных программ. Веб-страницы же, напротив, были маленькими, потому что вычисления выполнялись на стороне сервера. Распространение ПО в вебе стало виральным, для него достаточно было поделиться ссылкой.

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

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

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

              Почему веб не подорвал мобильные?

              Компьютер, который всегда с тобой, оказался очень важным. Мобильные поглотили мир. Это была кислородная катастрофа. Вопрос заключался в том, сможет ли веб выжить в кислородной атмосфере?

              На данный момент сетевое преимущество веба испарилось. Нативные приложения iPhone были Интернет-приложениями в «песочнице» и общались по HTTP, совсем как веб-приложения. iPhone был спроектирован для мира, включавшего в себя сеть. Веб не был спроектирован для мира, включавшего в себя iPhone.

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

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

              iPhone был чем-то совершенно новым. Он имел новое оборудование с новой моделью взаимодействия, и требовал новой ОС, новых приложений, новых примитивов UI. Всё это необходимо было интегрировать вместе, иначе продукт ждал провал. Представьте, каково было бы согласовывать всё это в процессе стандартизации. Это заняло бы годы! На самом деле, некоторые изначально необходимые аспекты, например, возможности устройства, спустя десяток лет после выпуска iPhone по-прежнему находятся на этапе обсуждения стандартов.

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

              Но разве веб не мог бы догнать её? Против этого работало несколько асимметрий…

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

              Навигация сместилась с клавиатуры на SpringBoard. Веб основан на поиске и URL. Поиск и URL спроектированы под аппаратные клавиатуры, благодаря чему легко вводить, копировать, вставлять и пересылать текст. Но на мобильных ввод текста неудобен. Толстыми пальцами печатать неудобно. Гораздо веселее нажимать значки на SpringBoard.

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

              Функции обнаружения программ и контента сместились с поиска в магазины приложений. Вместе с iPhone возникла его собственная система распространения. Магазин приложений упростил установку ПО, теперь для этого практически нужно лишь нажать на ссылку. Изучение тщательно контролируемого каталога приложений гораздо интереснее, чем ввод поискового запроса.

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

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

              Безопасность сместилась с «песочницы» на контроль приложений. «Песочница» веба обязана была аккуратно открывать API-доступ к таким вещам, как GPS, микрофон и камера. Их легко использовать злонамеренно, а поскольку веб обеспечивает свободные от ограничений инновации, при злонамеренном использовании которых никому нельзя пожаловаться. Нативные приложения обеспечивают доступ по всем возможностям устройства. Разработчики могут быстро экспериментировать и изобретать совершенно новые категории продуктов, например Uber. В то же время, проверка приложений позволила магазинам приложений принимать решения, одобряя или отвергая новые изменения, чтобы ограничить злонамеренное использование.

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

              Куда дальше будет двигаться веб?

              «Основная причина того, что мне важен веб, заключается в том, что это крупнейшая в мире платформа ПО, которая никому не принадлежит.» — Дейв Херман, TC39

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

              Desktop или Web?

              Так случилось, что я имею опыт разработки ПО под Desktop (в основном, на C++ и Qt) и под Web (PHP, Javascript). Под Desktop я разрабатываю проекты в-основном для себя и для научных исследований. Под Web я научился разрабатывать, чтобы мог периодически брать заказы на фрилансе (Очень редко попадаются заказы под Desktop, которые я с радостью беру, если они соответствуют моим компетенциям).

              Недавно преподаватель курса «Управление ИТ-проектами» пытался донести до нас одну мысль. Перефразирую, как понял:

              Делать проекты надо под Web. Разрабатывать под Desktop сейчас есть смысл только специфичные проекты. Web версию проще сделать кроссплатформенной, исправить, обновить.

              Преподаватель — директор по сопровождению и эксплуатации в Центре финансовых технологий, хороший специалист и очень классный мужик, поэтому спорить с ним не стал =)

              Предположим, что я хочу стать Project Manager’ом компании, разрабатывающей корпоративное ПО. Но клиентская часть корпоративного софта мне видится, как приложение под Desktop.

              1. Правда ли, что лучше разрабатывать ПО под Web? Почему именно так? Где об этом можно почитать?
              2. Как понять, когда нужно делать Desktop приложение, а когда Web приложение?
              3. Как менее болезненно разработчику Desktop приложений переквалифицироваться под Web разработку? Мне, как С++ разработчику писать на PHP и Javascript, мягко говоря, неуютно. Сейчас посматриваю в сторону C#.
              • Вопрос задан более трёх лет назад
              • 14491 просмотр

              Комментировать
              Решения вопроса 4

              Во-первых: Разработка под веб != PHP.
              Во-вторых: Грамотного проджект менеджера он неграмотного отличает способность делать обоснованный выбор технологий для каждого проекта не по советам преподавателя какого-то курса (насколько бы уважаем он не был), а исходя из специфики задачи (главное!) и (иногда) из наличия/отсутствия разработчиков с соответствующей квалификацией или наличия/отсутствия соответствующей квалификации у разработчиков (или разработчика).
              Да, есть такая тенденция, что десктор-приложения постепенно вытесняются веб-приложениями. И причины в основном кроются в, я бы сказал, «негибкости» десктор-разработчиков. Уцепившись за какую-то одну технологию (например .NET) они часто забывают, что их клиентское приложение — всего-лишь пользовательский интерфейс к бизнеслогике на сервере. Задача клиента — быть гибким, то есть не зависеть от окружения, в котором приложение запущено. Веб-приложения на 100% удовлетворяют этому требованию, они работают в любом (современном) браузере, под любой ОС, на любой мобильной/стационарной платформе и не требуют никакой предварительной подготовки среды (типа установки java, silverlight или adobe ). И только этим они побеждают. Для разработчиков по настоящему кроссплатформенных приложений (включая мобильные платформы), не завязанных на какую-то специфическую технологию (особенно проприетарную) и нетребовательных к среде исполнения, угроза со стороны наступающего веба — минимальная. Они еще долго будут спокойно сосуществовать рядом с веб-приложениями и ни один руководитель не упрекнет команду разработчиков в их выборе.

              Ответ написан более трёх лет назад
              Нравится 1 1 комментарий

              IGreench

              Евгений Липкин @IGreench Автор вопроса

              Спасибо за ответ!

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

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

              marrk2

              На С# в веб делать тоже нечего.
              Определять нужно веб-приложение или десктоп зависит от множества факторов:
              1. Безопасность (дубль на десктопе спокойнее)
              2. Доступность (evernote и без интернета можно открыть)
              3. Сложность (фотошоп в вебе нормальный ещё не придумали как и 3D-редактор)

              Я сам работаю на трёх ПК и конечно меня парит устанавливать нужное ПО на каждый из них, поэтому я обоими руками за веб-приложения.
              Сейчас все кинулись делать мобильные приложения, но и на них мода пройдёт, непонятно зачем фитнес-приложение или приложение СМИ ставить себе на телефон ведь вести программу тренировок и читать новости я и в вебе могу.

              Ответ написан более трёх лет назад
              Нравится 1 5 комментариев

              IGreench

              Евгений Липкин @IGreench Автор вопроса

              Спасибо за ответ!

              А можете привести более подробные аргументы по пунктам безопасности и доступности?

              marrk2

              Евгений Липкин: Если это финансовые данные то мне всяко надо их дубль иметь либо у себя на ПК либо на своём сервере, т.к. всякое бывает от пожаром до выемки серверов МВД. Про доступность всё проще вот мне надо идти в спортзал и хочу сейчас посмотреть программу тренировки а сайт недоступен, если у меня есть локальная копия — я открываю её.
              Раньше у меня было много ПО на компах а сейчас, ну программ 10 наверное — ФТП, фотошоп, IDE, Скриншотер, Офис, Антивирус и ПО для резервного копирования (связанное с веб-сервером) ну Криптографы ещё. Вот даже 8 а не 10.
              Есть специализированный софт, например парсер картинок, но я его переписал для себя и вынес с компа на веб-сервер потому что держать комп включенным ночью что бы спарсить 100 тыс. картинок неудобно и ВСЕ прикладные программы которые я пробовал на 60 тыс. зависали просто от размера списка. То же самое с любыми другими обработчиками.

              IGreench

              Евгений Липкин @IGreench Автор вопроса

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

              Пока всё это писал, понял, что наличие десктопной и мобильной версии софта также определяется надобностью хранения данных локально. Спасибо =)

              marrk2

              Евгений Липкин: ну безопасность бывает в плане «надёжности сохранения» и в плане «защиты от сторонних глаз» это разные безопасности )) А так рад что помог, удачи и проф. роста!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *