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

Однако в последнее время появилось множество не совсем точной, а часто и мифологической, информации о платформе. Это способствует завышенным ожиданиям у новичков. Такие мифы продуцируются как разработчиками no‑code, так и всевозможными курсами по обучению. И носят скорее рекламный характер, чем реальные характеристики инструментов.

Прежде чем анализировать мифы рассмотрим цикл разработки приложений на коде. 1) разработка UX дизайна (40 часов), 2) разработка UI дизайна (40 часов), 3) программирование бэкенда (120 часов), 4) программирование приложения для андроида (100 часов), 5) программирование приложения для iOs (100 часов), 6) тестирование (40 часов). Здесь трудоемкость каждого вида работ дана в часах для несложного приложения в 10 — 15 экранов. Естественно при увеличении количества экранов пропорционально будет увеличиваться и трудоемкость. Здесь мы не учитываем работу PM (прожект менеджера).

Эти цифры средние по нескольким украинским аутсорсинговым IT компаниям. Порядок выполнения работ параллельно‑последовательный: последовательно выполняются UX дизайн, UI дизайн, программирование (все три типа параллельно с некоторым опережением бэкенда), тестирование. Таким образом, общая трудоемкость составляет 440 часов, а продолжительность разработки составляет 240 часов.

Сразу отметим, что здесь не рассматриваются конструкторы основанные на шаблонах типа AppsGeyser. Они создают приложение за три шага: 1) Выбрать шаблон из 30 — 50 возможных (несколько кликов); 2) Добавить контент, например, логотип приложения, название, текст и ссылки, чтобы настроить ваше мобильное приложение (порядка 10 минут); 3) Загрузить приложение в Google Play Store. Здесь действительно практически не нужны знания, получается нативное приложение. К сожалению количество шаблонов десятки, а приложений нужно разрабатывать миллионы.

Теперь рассмотрим основные мифы.

Миф 1. Для разработки приложений не нужны специфические знания

Это утверждают как всевозможные курсы no‑code, так и сайты некоторых конструкторов приложений. Например, на сайте университет зерокодинга сообщают: «Вы можете легко освоить no‑code инструменты и понять как зарабатывать на этом уже через пару недель» а на сайте конструктора Unicorn Platform (https://unicornplatform.com/) пишут «Zero skills required».

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

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

Но вспомним, что в цикле разработки приложений имеется разработка UX и UI дизайна. Вкратце:

  • UX‑дизайн (User Experience — «пользовательский опыт») отвечает за то, как приложение работает.

  • UI‑дизайн (User Interface — «пользовательский интерфейс») отвечает за то, как интерфейс выглядит.

При плохом UX‑дизайне с приложением будет сложно работать и не каждый пользователь сможет получить нужный результат. При плохом UI‑дизайне приложение выглядит по крайней мере некрасиво и тоже затруднена работа с ним.

Каждому виду дизайна посвящены десятки книг. Поэтому если разработчик хочет получить удобное, красивое приложение он должен знать и уметь выполнять UX / UI дизайнерские работы.

Обучают UX/UI в некоторых ВУЗах. Также существует большое множество курсов. Время на освоение навыков UX/UI дизайна с нуля на курсах занимает порядка одного года.

Кроме общих знаний по UI дизайну для разработки мобильных приложений необходимы и специфические знания. Для iOs это Human Interface Guidelines, а для Android это Material Design.

Стоит отметить, что практически все конструкторы приложений не предоставляют функционал для UX дизайна. Наверное, исключением является GoodBarber (https://www.goodbarber.com/) — «конструктор приложений без кода для людей, серьезно относящихся к дизайну и UX». А также IDE DePro в которой выделяется функционал как для UX так и для UI дизайна. DePro сейчас находится в альфа тестировании.

Кроме дизайна имеется еще больший пласт необходимых знаний — базы данных. Хотя большинство конструкторов имеют свои средства работы с таблицами и убеждают пользователей, что это не сложнее таблиц Excel. Но это не совсем так. Это кустарная реализация микроскопической части баз данных. В конструкторах предоставляется функционал для описания таблиц и наполнения их информацией (ввод данных, удаление, замена). Кстати, эти функции более полно и качественно реализованы в каждой СУБД. Вне поля внимания остаются такие аспекты БД как проектирование, запросы (SQL) и пр. Нормальное обучение работе с базами данных осуществляют ВУЗы. Хотя очень поверхностное представление можно получит на курсах за пару недель, Но делать ничего не сможете, зато будет понятно сколько нужно всего учить.

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

Интересно, что компании, занимающиеся no‑code разработкой, при приеме на работу предъявляют к кандидатам реальные требования. Например, в телеграмм чате «Airtable Chat & Community» компания UDTech искала no‑code dev [mid; senior], со «стеком технологий: конструкторы — Bubble/Adalo/Flutter Flow, AirTable, Tilda; данные — DB, SQL, noSQL, микросервисы, REST API; языки — JS,.Net, Python».

Таким образом, после курсов по конструкторам вы сможете (не факт) разрабатывать простые плохо и медленно работающие, некрасивые приложения. И это будет до тех пор пока не освоите указанные выше знания.

Миф 2. Конструкторы позволяют в 10 и более раз ускорить и удешевить разработку приложений

Действительно, конструкторы позволяют ускорить разработку, но не в 10 – 20 раз.

Для оценки реального ускорения вспомним цикл разработки приложений на коде.

Из него видно, что общая длительность будет 80 (UX/UI) + 120 (программирование бэкенда) + 40 (тестирование) = 240 часов. При использовании конструкторов (которые позволяют разрабатывать и бэкенд) у нас время разработки будет только 80 часов. Итого мы в 3 раза быстрее разработаем с помощью no-code конструктора, чем на коде.

Оценим насколько дешевле разрабатывать конструкторами. В этом случае общие трудозатраты составят 440 часов. Т.е. с no-code будет дешевле в 5 с половиной раза.

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

Еще одним мифом из области скорости разработки являются сообщения на некоторых курсах no-code, что по завершению обучения будет написана копия airbnb (Uber, Amazon Marketplace, …). В компании Airbnb служба IT составляет более 500 человек, которые постоянно совершенствуют продукт. И никто не собирается заменить их "преподавателем" с курсов.

Миф 3. Приложения, созданные конструкторами, не уступают нативным на разработанным на коде

Сравнивать приложения можно по различным параметрам. Мы будем сравнивать по функциональности, которую можно характеризовать количеством (разнообразием) функций доступных при разработке приложений и качеством выполнения этих функций приложением.

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

  1. PWA (Progressive Web Application). Применяют такие конструкторы как Bubble, Glide.

  2. Кроссплатформенные фреймворки типа React Native, Flutter. Использует такие конструкторы как Adalo, Andromo.

  3. Нативный код. Swift для iOS и Kotlin для Android. Нативный код формирует, например, AppMaster, IDE DePro.

PWA при всех его достоинствах все‑таки разрабатывается WEB средствами и выполняется в браузере. Поэтому как бы не были визуально его элементы похожи на соответствующие в нативных приложениях, они функционируют по‑другому (не так плавно работают, нет многих возможностей и т. п.). Также не поддерживаются жесты широко используемые в нативных приложениях.

Конструкторы, использующие кроссплатформенные фреймворки создают приложения, работающие с нативными элементами. Но эти приложения имеют недостатки: размер приложений больше чем у нативных; производительность — ниже; безопасность — невысокая; увеличенный разряд аккумулятора. При этом React Native существенно уступает Flutter по производительности и размеру приложений.

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

Миф 4. Легко масштабировать и расширять

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

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

Одним из активно применяемых в последнее время no‑code инструментов для разработки бэкенда является Xano. На сайте задекларировано масштабируемость, в т.ч. горизонтальная. Однако в документации нет описания для реализации этого свойства (возможно пока). Контекстно подразумевается масштабируемость за счет использования PostgreSQL. Горизонтальное масштабирование, возможно, понимается возможность динамически менять регион сервера. Однако полноценной масштабируемости пока не достигнуто. Вертикальная и горизонтальная масштабируемость задекларирована и на сайте IDE DePro.

Еще хуже с расширяемостью. Фаворитами среди конструкторов являются Glide, Adalo, Bubble. Все остальные менее эффективны и не имеют значительной клиентской базы. Но даже эти конструкторы между собой не конкурируют. Каждый используется в своем диапазоне сложности приложений, которые с их помощью можно создать. И если возможностей какого ни будь конструктора недостаточно просто переходят на другой конструктор и, в конце концов, после MVP на код.

Миф 5. No-code разработчиков – миллионы

Например, на сайте конструктора bravostudio (https://www.bravostudio.app ) указано, что у них 100+ тысяч пользователей. Время разработки приложения — несколько недель. Значит, в течение года они создадут порядка миллиона приложений. Andromo (https://www.andromo.com/) — «более миллиона пользователей», они «создают несколько приложений в кратчайшие сроки». Адало на своем сайте вообще прямо заявляет, что ее пользователи создали более миллиона приложений. Существует множество и других конструкторов. И суммарно можно ожидать, что на no‑code разработано несколько миллионов приложений.

Однако, как известно, сейчас в Google Play Store каждый год добавляется около 1 миллиона приложений (включая игры). Еще больше приложений удаляется. Это связано с внедрением новых политик и правил безопасности и более автоматизированной проверкой приложений, которая часто удаляет даже нормальные и легальные программы. В результате в Google Play Store сейчас порядка 2,6 млн. приложений. Еще меньше приложений в App Store.

Что характерно, в статистике поступления в сторы новых приложений нет никаких всплесков увеличения их количества. Значит в Google Play Store доля приложений, разработанных с помощью конструкторов, очень маленькая.

Поэтому и количество no‑code разработчиков и количество разработанных ими приложений очень сильно завышено.

Заключение

1. No‑code инструменты разработки мобильных приложений будут совершенствоваться и займут свою нишу среди остальных инструментов.

2. Маркетинговые мифологемы возможностей no‑code инструментов приводят к завышенным ожиданиям потенциальных клиентов и, как следствие, разочарованию и отказу от них.

Комментарии (11)


  1. Vestibulator-1
    18.07.2023 06:44

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


  1. borovinskiy
    18.07.2023 06:44

    React Native компилирует код в нативное приложение. Оно нативное без всяких оговорок, просто логика написана не на Java/Swift/C#, а на JS и поэтому есть известная разница в том, насколько проще писать обработку тяжелых данных. По размеру тоже вопрос: React Native не таскает с собой свою версию webkit, поэтому размер у него вполне небольшой.

    А так спасибо за статью!


    1. hardtop
      18.07.2023 06:44

      Как это? С какого момента RN стал компилировать в натив?


      1. borovinskiy
        18.07.2023 06:44

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


        1. hardtop
          18.07.2023 06:44

          А, ну так вызов нативной api-шной кнопки через bridge всё же не полность. нативное приложение.


          1. borovinskiy
            18.07.2023 06:44

            Приложения под Android, написанные на Kotlin - тоже не полностью нативные?
            А написанные на Java с использованием JNI?

            Когда говорят про нативность, вопрос заключается прежде всего не в том, чтобы на Java/Swift писать, а в том, что интерфейс должен из нативных компонент состоять как противоположность подходу Adobe AIR / Apache Cordova / Flutter.

            Причем хочу заметить, что приложения на том же Adobe AIR под iOS компилировались в LLVM-код и фактически был нативным приложением, но вот компоненты интерфейса собственные, поэтому никто приложения Adobe AIR под iOS не называл нативным.


            1. hardtop
              18.07.2023 06:44

              Flutter хотя бы компилит в a-la натив, пусть и используя свой GUI-движок. Котлин тоже компилит в байт код, как и Java.

              А RN делает код, который запускает web-view, который запускает JS run-time совместно с JIT, и у нас 1 гб для мессенджера. Супер!


              1. borovinskiy
                18.07.2023 06:44

                Ну про 1 ГБ для простого приложения уже наверное преувеличили! Запустил свое приложение под react-native-windows и оно после старта потребляет 28 МБ.
                Да и кто мешает Hermes использовать как JS engine?


  1. Homosum
    18.07.2023 06:44

    Спасибо за статью! Реально не хватает таких отрезвляющих материалов.

    No-code через призму маркетологов превращается в глазах собственника/инвестора в супер инструмент: дешевый и быстрый. И потом приходится разрушать радужные мечты, что со сделанным MVP вы не станете вторым Facebook или Телеграмм.


  1. hardtop
    18.07.2023 06:44

    NoCode - как швейцарский нож: всё есть, компактно, симпатично, но все пользуются нормальными отвёртками, ножами и прочим инструментом.

    У меня вопрос больше стратегический. Написали быстро прототип, используя кубики конструктора. Нужен свой кубик - ждём, пока его сделают, или сами пишем код. Получается, надо знать экосистему Конструктора, и заодно и Кодировать (например, js, css, html, react). Получается, чтобы развивать прототип, надо уметь кодить.

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

    Чем NoCode отличается от использования всяких фреймворков и UI китов? Точно так же набрали компонент и связываем их. Чуть сложнее на старте - гораздо гибче и производительнее в будущем.


    1. jura-49 Автор
      18.07.2023 06:44

      Совершенно верно. Особенно проявляется "программистская" основа в конструкторах у которых имеется работа со сценариями. В сценарии под кубиками закамуфлированы практически все конструкции алгоритмических языков