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

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

  • автор:

Десктопное приложение или веб-клиент – вот в чем вопрос!

Десктопное приложение или веб-клиент – вот в чем вопрос!

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

«То о бэнтли я мечтал, то о мазерати,
То рыбалка, то футбол, то с друзьями пати…»
Группа Жуки
​Захотелось мне что-то провокационной статьи, так сказать, взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!

Правила игры и критерии оценок

  • Десктопное приложение – клиентское программное обеспечение, реализующее Windows Forms интерфейс. Приложение инсталлируется на рабочую станцию пользователя и запускается локально. Или запускается удаленно. Допускается вариант запуска такого приложения с использованием ввода URL адреса в браузере, но от этого веб-клиентом не становится, также как и благодаря запуску с помощью различного рода эмуляторов;
  • Веб-клиент – клиентское программное обеспечение, представляющее собой браузер и использующее http/https протоколы. Приложение не требует инсталляцию или загрузку программных модулей на рабочую станцию пользователя. Допускается установка дополнительных общесистемных библиотек и использование защищенных сетевых протоколов, и от этого десктопным приложением не становится.

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

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

  • функциональность, простота использования и быстродействие;
  • возможность кастомизации и стилизации;
  • мобильность и легкость обновления;
  • масштабируемость и кроссплатформенность;
  • безопасность и надежность.

Для простоты будем считать, что каждое удачное попадание – 1 очко, так как бессмысленно сравнивать, что важнее – мобильность или безопасность.

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

Первый период

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

Как правило, обоснования такие:

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

Часть этих преимуществ можно достичь и в варианте с десктопным приложением используя RDP доступы, доменные политики и прочее. Но в целом, удар из штрафной площади и 1-0 в пользу веб-клиента. Свисток, центр поля.

Безопасность и надежность – очень серьезный вопрос. Некоторые организации принципиально не хотят и не предоставляют возможность работы в корпоративных системах за пределами своего домена. Необходимость применения средств криптографической защиты информации (СКЗИ) и электронной подписи (ЭП) уже давно никому доказывать не надо, за нас это делают регуляторы. Для использования данных технологий необходимо обращаться к сторонним библиотекам, не все веб-приложения это «любят» и имеют ограничения. Стабильность работы самих браузеров также является потенциально узким местом, причем повлиять на это разработчик бизнес-приложения может не всегда. Оффлайн работа, объективно, чаще и проще реализуются с использованием десктопных приложений. В принципе отдельных организаций пока еще пугает работа в браузере (да-да в том самом, в котором сотрудники просиживают часами в социальных сетях, выкладывая туда всю свою подноготную). Это прорыв по флангу и счет 1-1. Звучит свисток, первая половина игры закончена, команды уходят в свои СЭД закрывать накопившиеся поручения.

Второй период

Все покупатели хотят видеть «свой» продукт, отличный от множества других. Конечно, сложно на это надеяться, покупая массовый коробочный продукт. А сделать его «под заказ» значительно дороже и рисково. Но только не в IT области.

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

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

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

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

Современный пользователь компьютера не меньше времени проводит в браузере, чем тратит его на работу с десктопным приложением. И первый вариант работы сложнее ему не кажется. Зато возможность масштабирования в браузере, отдельным категориям пользователей, приносит ощутимую пользу. Опасность у ворот команды веб-клиента была устранена. Счет по-прежнему 2-1.

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

Разрабатывая веб-приложения с соблюдением стандартов можно надеяться, что программное обеспечение будет корректно работать во всех браузерах, по крайней мере, в первой пятерке. Чуда тут не происходит, и существует масса нюансов связанных с различной интерпретацией одной и той же разметки. Разработчики каждый день видят в системах баг-трекинга заявки из разряда «функция А не корректно работает в браузере Б, а в остальных браузерах все ОК». Но эти труды стоят получаемых бонусов.

Когда пользователь заходит на рядовой публичный сайт в Интернете он надеется увидеть корректное представление страниц с сохранением всей заложенной функциональности. Причем, посетитель сайта не хочет знать «под какие устройства» сайт создавался (стационарный компьютер или ноутбук, планшет или смартфон), это его вообще не должно беспокоить. Почему же ровно также не рассуждать пользователю корпоративной информационной системы. Зачем пользователю, находящемуся вне офиса и имеющему на руках планшет за 1000$ переживать, что он не сможет исполнить поручение, выданное ему в СЭД. Надо ли сотруднику при выборе планшета изучать вопрос, а сможет ли он конкретно с этого планшета (с его операционной системой), корректно работать в десятках корпоративных систем своей организации. А если завтра он купит другой планшет (с другой программной платформой), система на нем будет ровно такой же, к которой он привык или уже другой, а придется что-то заново скачивать и устанавливать?

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

  • Кейс — корпоративный чат-бот компании
  • Доступ к цифровым профилям сотрудников. За и против
  • Чек-лист для внедрения роботизации
  • Как повысить окупаемость инвестиций в корпоративные приложения

Послесловие

После матча болельщики еще долго спорили, обсуждали острые моменты и не объективное судейство, но счет на табло уже ничто не изменит. Ставки сделаны господа, ставок больше нет!

Какое приложение подходит вашему бизнесу: web или desktop

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

В чем отличия web и desktop приложений?

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

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

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

Десктоп-приложение Веб-клиент
Нужен ли интернет? Нет, так как программа работает локально Да, нужен обязательно. Только у некоторых веб-приложений есть автономные функции.
Установка и обновление Для работы требуется установить приложение на каждое пользовательское устройство и своевременно обновлять программу. Для работы с веб-клиентом нужна единовременная настройка, которая будет одинаковой для всех пользователей. Обновление также является централизованным.
Интерфейс взаимодействия Предполагается стандартный интерфейс взаимодействия Интерфейс взаимодействия разнообразен.
Совместимость с железом Программа разрабатывается для определенной платформы, хотя могут быть и кроссплатформенные приложения. Может работать на устройстве с любой ОС.
Графика и анимация Максимально быстрый отклик. Отклик более медленный и зависит от скорости передачи данных.
Мультимедиа Сложности с воспроизведением аудио и видео возникают редко и являются незначительными. Могут возникать проблемы, если все реализуется через Flash. При внедрении стандарта HTML5 обеспечивается поддержка аудио и видео через браузер.
Набор шрифтов Можно использовать только те шрифты, которые установлены на устройстве. Выбор шрифтов намного шире, так как недостающие можно загрузить через интернет.
Поиск информации Возможен поиск данных, если такая функция реализована на уровне программы. Можно организовать поиск по контенту, в том числе и при помощи сторонних сервисов.
Совместный доступ Расшаривание нужно настраивать дополнительно. Приложения изначально ориентированы на совместное использование.
Разработка Каждая программа предназначена для определенной платформы, поэтому может потребоваться несколько версий для разных устройств. Веб-приложения являются кроссплатформенными. Все задачи выполняются через сервер, поэтому можно заходить с любого устройства и через любой браузер.
Распространенность Десктопные программы распространены повсеместно. За последнее время популярность веб-клиентов сильно выросла. Появились новые сервисы, которые по функциям дублируют десктопные программы и являются такими же надежными.
Тестирование В тестировании участвует сравнительно небольшая группа людей. Благодаря размещению приложения в интернете к тестированию можно привлечь огромное количество пользователей. Это позволяет быстро обнаружить недочеты и избежать некорректной работы.

Почему веб-приложения выходят на первый план?

Вы можете убедиться, что по скорости работы, надежности и безопасности современные веб-приложения не только не уступают, но даже могут превосходить десктопные аналоги. Выбор в пользу веб-клиентов делают крупнейшие игроки рынка, в том числе Google. Они используют формат PWA (progressive web-application). Особенность таких программ заключается в том, что они являются веб-клиентами с функциями десктопного приложения. Например, многие пользователи хранят документы в Google Docs, используют веб-интерфейс для просмотра писем в Gmail. Популярность таких программных продуктов постоянно увеличивается благодаря их функциональности, простоте использования, мобильности, кроссплатформенности и безопасности.

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

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

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

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

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

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#.
  • Вопрос задан более трёх лет назад
  • 14737 просмотров

Комментировать
Решения вопроса 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

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

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

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

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

Я работал над пятью браузерами и одной операционной системой, наблюдая за тем, как этот вопрос оказывается связанным с 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

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

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

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