Блочная мобильная разработка: выхода нет?

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

Если пользователи каждый день сталкивается с багами среды разработки, с неудобной работой в ней, с невозможностью сделать то, что хочется, с непонятно как сделанной документацией, с невозможностью отладки приложения и многим другим, то почему они упорно продолжают пользоваться такими инструментами? Потому что эти инструменты создают видимость чрезвычайной лёгкости и простоты создания мобильных приложений. Неужели это ощущение простоты перевешивает все связанные с этим недостатки, включая невозможность создания качественных мобильных приложений? Да, для многих пользователей основным критерием выбора инструмента для разработки мобильных приложений является простота их создания. Такие пользователи живут настоящим и, если платформа здесь и сейчас позволяет что-то сделать,  то на ней они и будут работать. Более того, ради одного компонента или нужного блока они готовы ждать месяцы, пока разработчики не соизволят их сделать. Когда же этот это появляется, то первым делом пользователи рассыпаются в благодарностях, несмотря на то, что это откровенно сырые и нерабочие компоненты. Не хочу делать никаких намёков, но в такие моменты возникает ассоциация с собакой, которой соизволили бросить кость от курицы. ”Так перестаньте заниматься ерундой! Изучайте Java”, - посоветует каждый второй. Совет хороший, вот только он не подходит не всем. Можно, конечно, пойти учиться лет на 5 в детскую музыкальную школу, но для чего это нужно человеку, который хочет просто научиться играть на гитаре “дворовые” песни?

Принципиальное отличие пользователей от программистов состоит в том, что пользователи хотят получить готовое решение их задачи быстро и желательно с минимальными усилиями, чего не может предложить им ни Java, ни другой язык программирования, который придётся изучать.  Если же пользователь плотно присел на блоки, то он вообще перестаёт воспринимать текстовой код, даже если этот код способен решить проблему, над которой он бьётся уже не одну неделю. Маркетологи так промыли им мозги, что при виде даже готового кода, пользователи бегут от него и предпочитают городить сотни повторяющихся блоков ради идеалов весьма спорной концепции, говорящей о том, что каждый сможет без текстового кодирования создавать восхитительные мобильные приложения. Вот они и мечутся от App Inventor к Kodular, от Kodular к Thunkable X или Sketchware в поисках идеальной платформы,а точнее утопии,  которая позволит им без особых знаний и усилий создавать “опупенные” приложения. Почему это утопия? Откройте руководство разработка Android и посмотрите на функциональность API. После этого откройте документацию по разработке под iOS. А теперь ответьте на вопрос, сколько блоков и компонентов нужно запихнуть в блочную платформу, чтобы она покрыла хотя бы 20% данных возможностей без багов, насколько эту махину будет легко поддерживать в рабочем состоянии и легко её пользоваться. В Google работают неглупые люди, которые сбагрили App Inventor и остались весьма довольны этим фактом. Разработчики Kodular рискнули пойти по этому пути, и в результате получилось бесполезное месиво из кучи компонентов и блоков, привести в порядок которые можно только одним способом – всё удалить и начать по новой. Разработчики других платформ гораздо более осторожны, так как они прекрасно понимают то, на чём держатся их платформы.

Что же тогда делать, если учить Java и другие языки программирования не хочется (или нет возможности)? Сидеть на блоках и ждать, когда разработчики добавят в них блок для изменения цвета шрифта в списке?  Я вижу только один практичный выход – изменить свой подход к блочной разработке и перейти к созданию гибридных мобильных приложений, воспользовавшись функциональностью web-технологий. Если вместо ”нативного” UI использовать  компоненты того же Framework7, то, во-первых, это на порядки увеличит возможности по созданию интерфейса и отзывчивости в его работе, а во-вторых, на порядки сократит количество багов. Но для этого нужно будет пересмотреть всю концепцию и в разработке мобильных приложений отталкиваться от web, когда нативная функциональность является вторичной и используется только тогда, когда web не имеет средств для её реализации.

Маловероятно, что разработчики блочных платформ захотят заменить компоненты нативного интерфейса на компоненты Framework7. Позволить Web Viewer стать основным компонентом? Да никогда! Уж лучше пусть наш список из 20 записей на iPhone грузится 5 секунд, чем мы позволим HTML зайти в мобильную разработку.

Можно долго спорить о преимуществах родных приложений перед гибридными, но я считаю, что в любом приложении должны использоваться качественные решения и технологии. Если web-компоненты  превосходят по всем параметрам  “нативную реализацию”, то именно их и нужно использовать. В чём проблема? В необходимости пересмотра устаревших программ обучения по блочному программированию, в рамках которой ещё многие годы будут учить создавать интерфейсы при помощи блоков. Вам это ничего не напоминает? Basic и Pascal потеряли актуальность ещё лет 20 назад, но их до сих пор пытаются проталкивать в образовательном процессе.

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