19 августа 2018
Беседка №202. Атака на Android
Илья Субботин
Первая часть материала о том, как альтернативные инструменты разработки под Android могут «увести» ОС из под влияния и контроля Google…
Сегодня я не буду писать о том, как уволился из Google, как сообщество отреагировало на мой материал о причинах этого решения. Сегодня я немного поговорю об Android и своём собственном мнении о нём с позиции человека со стороны и разработчика-любителя под Android и iOS.
Я размышляю об Android по причине необходимости приёма на работу разработчиков под мобильные устройства — вполне простая и незамысловатая задача, как вам может показаться. Но, оказывается, такие специалисты на сегодня пользуются максимально высоким спросом на рынке. И их поиск можно сравнить с ловлей единорогов.
Зачем всем понадобились разработчики под мобильные устройства? Потому, что «веб» медленно умирает. У меня есть – хотя, наверно, уже были – друзья практически в каждом подразделении Google. Они часто показывали мне свои печальные диаграммы, и как их ни рассматривай, становилось ясно, что популярность традиционного «веба» постоянно снижается по мере того, как весь мир переходит на мобильные платформы. Что уж говорить, вы, наверно, помните период перехода Facebook от акцента на веб-платформе к преимуществу в пользу мобильных устройств. Facebook едва не сыграл в ящик. Конечно, не одним днём, но компания прошла через экзистенциальный кризис и осознала, что либо компания возьмёт курс на мобильные приложения, либо примет неизбежный конец. Они справились, но было невероятно сложно. Всё дело в максимальной мерзости структурной иерархии базы разработчиков под Android.
Неприятная «кухня»
Большинство специалистов в Google слишком высокомерны, чтобы заниматься разработкой под веб или мобильные платформы. «Я не занимаюсь фронтендом (разработкой клиентской части приложений)», — провозглашают они с максимальной заносчивостью. На вершине пика высокомерия восседают выспренные разработчики под C++ для Поиска, который считается круче, чем Java, который считается круче, чем Python, который считается круче, чем Javascript. А Поиск круче, чем Реклама, которая круче, чем Приложения, которые круче, чем Инструменты, которые круче, чем Frontends. И так далее. Программисты обожают смотреть свысока друг на друга. И если вам не повезло работать над разработкой мобильных продуктов Google, то вы окажетесь у самого основания нескольких «тотемных столбов», где за вами будут с презрением наблюдать все остальные.
Пройдя в своё время через всё это великолепие – от системного программирования до крупномасштабной инженерии данных, проектирования компилятора, Services Framework, разработки игр, мобильных и веб-продуктов — я могу заверить вас, что фронтенд ничем не проще, может, даже сложнее. Всё, что касается разработки серверной части продукта, выглядит приятным, опрятным, организованным, рассредоточенным и параллелизуемым. Это просто рай по сравнению с безумным бардаком в веб-программировании по итогу 25 лет его существования. Но даже веб-программирование сравнимо с приятным путешествием на Бали на контрасте с программированием под мобильные платформы, включая iOS.
А Android? Ну, да. Более мерзкого ничего не придумать. Разработчики под Android – герои. Программирование огромного по охвату приложения (Google Maps, Facebook, Snapchat) под Android не описать словами, вы мне не поверили бы, если бы я даже попытался. Вот ты сидишь и ждешь 20 минут, чтобы посмотреть, что же произойдёт после того, как ты изменил одну строку кода. И каждое внесённое изменение, каким бы незначительным оно ни было, с вероятностью 80% не будет работать с первого раза. Причиной этому является странная скудность данных о взаимосовместимости. Вы можете использовать и X, и Y, но не получится использовать X вместе с Y, ибо гуляй лесом, дружище.
И не смейте даже заикаться о совместимости устройств. На странице моей игры в Google Play Store куча гневных оценок с рейтингом 1*, появившихся там просто потому, что приложение по непонятной для меня причине отказывается работать на устройствах LG. Поэтому мне пришлось заходить на eBay, покупать несчастное устройство от LG за 60 долларов, чтобы воспроизвести ошибку и обнаружить, что, эй, есть два API для Android, позволяющие отобразить события нажатий мыши на прокручиваемом списке, но один из этих API не работает на LG. Вы серьёзно, может, хватит?
И вот что произошло: ряд конкурентов, крупных и не очень, выкатили свою альтернативу среде разработки Android. Я не говорю о вспомогательных библиотеках для отсутствующей функциональности, хотя их существует множество. Нет, я о полноценных альтернативных решениях для комплекта инструментальных средств для разработки под Android от Google. У Microsoft есть Xamarin, у Adobe – Cordova, у Facebook – React Native, можно свихнуться. Посмотрите сами: Framework7, Appcelerator Titanium, Onsen, Sencha, Kendo, XDK, Ionic, Mobile Angular, Unity, серьёзно, что, черт побери, происходит?
Как будто все, кто пытался программировать под Android, сдались и заявили: «Это настолько ужасно, что я создам свой стартап, который всё исправит». А Google, чтобы не быть обставленной конкурентами, ответила: «Ах так? У вас не получится с нами соревноваться, потому что мы будем соревноваться сами с собой!» — и запустила Flutter, который является (я ничего не придумываю) на сто процентов самостоятельным комплектом для разработки под Android и соперничает с таковым по умолчанию. Официальная команда разработчиков под Android отказывается признавать его существование. В интересное время живём, однако.
Атака на Android
Все эти инструменты делают Google уязвимой. Большинство из них доступны для разных платформ, что означает возможность написания одного приложения, которое будет работать и на iOS, и на Android. Неважно, кто вы – крупная компания или небольшой магазинчик, никто не хочет платить двум командам разработки за идентичное приложение для разных платформ. И поэтому есть огромная экономическая мотивация для миграции на кроссплатформенные решения. Единственным препятствием на пути этой массовой миграции является то, что эти инструменты пока что не дотягивают до качества «нативной» разработки.
Но некоторые из них подбираются очень близко, особенно Facebook React Native. И если кто-то из них сможет уцепиться за достаточно большую долю рынка, то Android, по сути, станет проводником для экосистемы разработчиков, которая больше не находится под контролем Google.
Это может показаться чем-то малозначимым, ведь у Google всё ещё есть Play Store, OEM-партнеры, лицензирование и так далее. Для большинства пользователей их вышестоящее положение выглядит комфортным. Но стоит учесть вот что: если все разработчики под мобильные платформы начали бы пользоваться определенным кроссплатформенным инструментом Х, то практически любой производитель «железа» или «софта» мог бы выйти на рынок с конкурирующим «железом» или «софтом» (как, например, Windows) с прямой поддержкой X и более быстрой работой и запуском приложений, тем самым исключив Google из этой цепочки. И, поверьте мне, многие компании жаждут этого. Извиняюсь, не многие, ВСЕ. Да и кто был бы против?
Реакцией Google на эту ситуацию стало ещё более тщательное следование собственной стратегии. В компании в два раза усилили акцент на нативном (традиционном) программировании под Android с официальной поддержкой языка Kotlin, который является прорывом для использующих нативный комплект разработчика. Я обожаю Kotlin, за ним – будущее Java. Но стоит признать: рынок мобильных платформ движется не в его направлении. Люди «пишут» кроссплатформенные приложения по двум главным причинам:
- Они хотят, чтобы приложение их компании работало на двух платформах без надобности удваивать масштаб работ.
- Нативное программирование под Android всё ещё требует больших усилий, даже с Kotlin, многие компании справедливо чувствуют, что нужно выбросить всё и начать с самого начала, осуществив переход на более простое решение.
Если вы являетесь разработчиком под Android или iOS и сможете уделить время для изучения React Native, который был создан Facebook именно для решения этих проблем, то вам хватит тридцати секунд, чтобы понять, насколько он лучше. Конечно, мы подразумеваем, что вы не «пишете» игру, в этом случае всё равно придётся использовать Unity. Для бизнес-приложений и офисных утилит React Native предлагает сносную производительность, кроссплатформенную совместимость, замечательные инструменты и значительно повышенную скорость разработки. Помните, как я говорил о двадцати минутах ожидания, чтобы увидеть последствия изменения в одной строке кода в нативном комплекте разработки под Android? Так может происходить в самых крупных приложениях, таких как Nest или Facebook, но даже для средних по размеру приложений это займёт 2-3 минуты, в то время как в React Native всё происходит мгновенно. Внесли изменения – увидели результат.
И это, друзья, означает возможность запуска новых «фишек» в десять раз быстрее, что даёт более быстрый выход на рынок, преимущество первого хода и сплошной выигрыш. Отказ от нативного программирования в пользу быстрых кроссплатформенных инструментов является выигрышной стратегией.
Автор — Стив Эгг
Стоит отдать должное разработчикам под Android, судя по описанию «разработчика-любителя» им приходится совсем не сладко. Новые, более современные и более быстрые альтернативные инструменты для разработки угрожают поместить Google в позицию догоняющего, и желающих отцапать лакомый кусочек у «корпорации добра» предостаточно. В Маунтин-Вью пока что верят в правильность своего пути, на всякий случай держа Flutter наготове, но не признавая это. Допустит ли Google неблагоприятное для себя развитие событий? Кто готов претендовать на «трон»? Об этом — в продолжении этого выпуска через неделю.
Супер! Этот чувак Стив Эгг не какой-то там болтун, которому не досталось шоколадное пирожное. Ушел из Google, потому что они по его мнению «высокомерные» и «погрязли в политике». Молодец короче он. Спс за материал.
Я, конечно, не знаю тамошней кухни, но очень уж он высокомерен.
>>Что уж говорить, вы, наверно, помните период перехода Facebook от
акцента на веб-платформе к преимуществу в пользу мобильных устройств.
Не помню.
>>Но даже веб-программирование сравнимо с приятным путешествием на Бали на
контрасте с программированием под мобильные платформы, включая iOS.
Ах, позвольте не согласиться, в плане iOS.
>>Но некоторые из них подбираются очень близко, особенно
Facebook React Native. И если кто-то из них сможет уцепиться за
достаточно большую долю рынка, то Android, по сути, станет проводником
для экосистемы разработчиков, которая больше не находится под контролем
Google.
Ох, сколько раз это уже было… На винде была Delphi, которая, действительно, позволяла не заниматься сексом с MFC, и была быстрой и лёгкой. И кроссплатформенной (kylix). Разработчики всё равно больше доверяют инструментам той компании, которая разрабатывает ОС.
Костя, это не высокомерие, это погружение в тему. Когда человек чем-то занимается постоянно, то ему начинает казаться, что это так важно, что аж прямо ппц. И все думают также, как бе) А вот не как бе)
Согласен
у меня ест ощущение, что делфи по больше части была популярна в странах Варшавского договора.
Судя по вакансиям западных стран — VB и Access были полновесной альтернативой.
выход messenger, покупка вацапа и инстаграмма.
ну и ещё куча экспериментов которые закрылись.
Замечу, что не только была, а и есть 🙂
И кросс-платформенность Delphi уже раскинулась на Android, MacOS, iOS, Linux (FMX, FGX на подходе), Веб (UniGUI, TMS Web)
+1. Только не сразу понял, что «Стив Эгг» — это тот самый Стив Йегге, который пишет свои blog rants (блог, посвященный разным вопросам программирования) года так с 2006-го, имеет огромный опыт разработки, работал в Google и вообще не абы кто, а эксперт, к словам которого стоит отнестись с интересом.
Спасибо за интересный материал
Фукция
Эх, когда же у меня уже дойдут руки до Xamarin…
Не знаю кто это, но если после перевода на русский статья полностью понятна и легко читается товарищ как минимум имеет прекрасный мозг. В кои-то веки тут прочитал внятный текст, а не мутные переводы мутных излияний невротичных «гуманитариев». Спасибо.
Ничего штатным средствам разработки и соответственно Гуглу не грозит. Ну не перейдут все или хотя бы весомая доля, на единый альтернативный. Во1х, даже на просто альтернативный, никто не станет переписывать уже существующие приложения среднего и малого класса. А во2х, единство не возможно, всегда найдется лучшая альтернатива. Либо из существующих, либо напишут новое.
Создатель хорошего инструментария Х, может получить небольшую фору на старте своих ОСи или железа, но о большем можно продолжать мечтать. И да, на десктопе, есть разные графические компоненты (VCL, Qt, GTK и др), есть разные кроссплатформенные языки программирования и среды разработки, но MS контроль не теряет. Значит и Гуглу ничего не грозит.
кроссплатформа — это когда программист решает свои проблемы, а не проблемы пользователя.
писал весной домашний проект на реактнейтиве. нашёл 2 бага которые описал в репо. один из них такой — по дизайну кнопка должна быть 50% экрана и иметь скруглённые углы. на ios это так, на ведре — кнопка прямоугольная и обжимает текст.
поддержка iphonex для прокручиваемых список на RN — боль.
короче, RN, да и другие кроссы — это для быстрых прототипов или как можно быстрее выйти на рынок не имея ресурсов, т.е. для слабаков.
странно, что решили перевести эту мартовскую статью. летом этого года был интересный «инфоповод»:
пробовал phone gap в 2013 — оказалось, что нейтив для меня быстрее ДЖС-а
а хамарин на мак-е — в топку, даже весной этого года.
В целом верно, решение всегда существует под задачу и только укушенные маркетологами, натягивают сову на глобус, выдумывая задачи под решение. Однако нехорошие эпитеты тут лишние. Это извечное противостояние, в целом обзываемое «универсальное vs. специализированное». Камера или звук в универсальном смартфоне против специализированного плеера или фотика. Универсальный планшет против eInk ридера. У каждого полюса найдутся свои сторонники, и у каждого сторонника, найдутся аргументы в защиту своего выбора и уничижающие эпитеты в сторону «противников». Давайте жить дружно)))
эпитет может звучит и жестоко, но зато правдиво 🙂
выбирая кросс — значит кампания слаба в денежном выражении, иили инженерном.
Она не может быть слаба, она может быть слабее чем монстры рынка. Не всем быть Фейсбуками.
И да, про заносчивость и высокомерие написано в самом начале статьи, еще даже до постановки проблемы.
Или умеет считать деньги ))).. Если результат получаемый на кроссе устраивает полностью, то нет смысла палить бабки на двойную/тройную работу… Работает и хорошо, пользователям чаще всего пофиг как, а палить бабки чисто чтобы потешить самолюбие отдельных личностей — это тупо и не эффективно.
проблема в том, что на кроссе не бывает отличного результата. максимум 3+.
Иначе бы AirBnB, Udacity не соскочили бы с реакт-нейтив, а допустим, те же убер или яндекс такси не пили бы native.
«Если результат получаемый на кроссе устраивает полностью» ))) их вполне может устраивать то, что вы характеризуете как 3+…. Короче не суть важно как оцените результат вы, главное чтобы устраивало заказчика )))
Что касается флаттера.
мертворожденный аналог флеша.
1) эта технология сама рисует интерфейс, пиксель за пикселем. т.е. тупо мимикрирует. это мы проходили с флешем в вебе.
2) у неё нет возможности использовать компоненты платформы map и webview как компонент на странице. а это ограничения по дизайну и пользователским сценариям.
лучше уж реакт.
>Я не занимаюсь фронтендом (разработкой клиентской части приложений)»,
Откуда такая дикая терминология? Фронтенд это обычно сервер, доступный клиентам (повернутый к ним лицом), который балансирует нагрузку на стадо стоящих бэкендом (за его спиной и невидимых клиентам) серверов, нпр. DNS или серверы БД.
Вообще-то это общепринятая терминология в веб-разработке. Терминология из мира серверной инфраструктуры и системного администрирования не является и не может являться общепринятой.
в каждой предметной области свой глоссарий (:
Интересная статья, хоть и тупо перевод с оригинального текста.