Трудности перевода

Разговоры о всевозможных новых магазинах приложений уже успели утомить. Так часто бывает, когда некомпетентные люди предлагают простые решения сложных проблем. И комментировать всевозможные «идеи» на эту тему, мы разумеется, не будем. Потому как ошибочность подобных подходов к проблеме мы разбирали ещё 3-4 года назад и с тех пор ничего не изменилось.

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

Другой путь, наоборот, предполагает переписывание всего что есть в виде веб-приложений. Тут тоже всё понятно. Известные ограничения iOS подталкивают именно в эту сторону. Так сказать, возвращение к истокам. Если кто забыл, то изначально Стив Джобс был против загружаемых приложений и считал что сторонний софт должен исполнятся в браузере. Поэтому никакого AppStore в первом айфоне не было. Если вам нужные какие-то сторонние сервисы — держите айфон правильно и используйте браузер.

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

Однако первоначальный оптимизм в отношении мобильных веб-приложений довольно быстро начал угасать. Внезапно оказалось, что ничего бесконечного не бывает. В том числе ежегодного кратного прироста вычислительной мощности смартфонов. И маятник очередной раз качнулся в сторону нативных приложений. Тут можно было бы уйти в ещё дальше в прошлое, стряхнуть пыль с Netscape Navigator, вспомнить Java-апплеты, войну Sun и Microsoft и всё те же самые идеи и аргументы. Но этого делать мы не будем. Как и вспоминать историю Adobe Flash и безуспешные попытки продлить его жизнь с помощью JS-эмуляторов.

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

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

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

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