QML для просмотра в браузере или браузер для просмотра QML?

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

C появлением web-фреймворков, HTML5, CSS3, новых стандартов JavaScript и др. ситуация в web-разработке улучшилась и упростилась, но неизменным осталось то, что web-интерфейс по ряду значимых параметров уступает и настольному, и мобильному. Почему? Потому что браузерная среда по своей природе не позволяет шагнуть в этом направлении качественно:

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

Речь идёт о системных элементах по той причине, что они являются привычными и удобными (родными, нативными) для операционной системы. Они функциональнее, стабильнее в работе и продуктивнее по сравнению с элементами html. Но при первой возможности web-разработчики избавились от "серых кнопок" и в клиентской части web "двинулся" в сторону дизайна, а не содержания. Появились страницы без системных элементов формы. А зачем они нужны, если всё может <div>? Может-то и может, но скорость например, системного списка ощутимо быстрее div-списка, а время от времени возникает большое желание всё как-то ускорить в клиентской части web.

Некоторые системные элементы оконной операционной системы (кнопка, поле ввода, радиокнопка, флажок и др.) были реализованы в браузерной среде и существуют в ней с теми или иными ограничениями и особенностям. Затем этот "фарш" вместе с особенностями самой браузерной среды возвращается обратно в настольную и пытается залезть в мобильную в виде гибридных приложений с web-интерфейсом. Получается это не слишком хорошо. Приходится прибегать к помощи адаптивного дизайна и многочисленных фреймворков типа React Native, jQuery mobile, PhoneGap и др.

Web-интерфейс по функциональности и удобству проигрывает родным интерфейсам, но ради красоты, доступности и кросс-платформенности он всё равно берётся за основу, а элементы системной среды раз за разом пытаются компилировать под браузеры! На выходе получаются всё те же "серые кнопки", но значительно хуже первоисточника, а между тем есть и альтернатива.

В общем случае можно выделить web-интерфейс, настольный и мобильный. Отнесём web-интерфейс и настольный к оконному, а настольный и мобильный - к родному (нативному). Если стоит задача создания универсального интерфейса, с которым будет удобно работать и в настольной, и в мобильной среде, то вопрос заключается в том, что выбрать в качестве основы для него. Если превыше всего стоит доступность, то здесь нет равных web-интерфейсу, если функциональность - настольному. Но настольный и web-интерфейс недостаточно хорошо вписываются в мобильную среду. Значит, имеет смысл обратить внимание на мобильный, дополнив его возможностями двух остальных. То есть, вести разработку не от настольных систем к мобильным, а наоборот или одновременно, что ещё лучше. Для этого потребуется кросс-платформенная технология. Здесь можно вспомнить Java, С#, С++, Python, Lua и ещё пару десятков вариантов, но для популяризации данной идеи требуется язык, обладающий следующими характеристиками:

• Простота в изучении и использовании
• Функциональность и стабильность в работе, близкую к front-end стеку
• Не требует компиляции и использования сторонних технологий и фреймворков
• Для него имеется кросс-платформенная среда разработки с удобным предварительным просмотром на разных устройствах

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

Чем больше я вижу программных технологий, тем чаще возникает мысль о том, что они должны быть проще, значительно проще. Пакетные установщики, автоматические системы сборки, компиляторы и др. кажутся простыми в работе, но в сумме приходится вникать в десятки программных решений, потому что это лучше использовать с одним и с одними случаями, а то - с другим и в других случаях. Но нередко выбор технологии основывается не на том, сколько платят за работу с ней или её функциональности, а на простоте и возможности использования. Если для запуска программы "Привет, мир!" на одной технологии требуется выполнить 10 шагов и 30 минут установки, настройки и отладки, то многие ли выберут её, когда вокруг полно альтернатив, где всё это можно сделать за 3 шага и 5 минут?

Казалось, что с появлением многоядерных процессоров проблема постоянной нехватки мощности для выполнения программ ушла в прошлое, но это не так. Новые операционные системы и среды разработки требуют ещё больше процессорной мощности, ещё больше оперативной памяти, ещё больше скорости от жестких дисков. В 2007 году продавец с улыбкой недоумевал, зачем для 4-х ядерной системы с процессором 2.8 ГГц 16 Гбайт оперативной памяти, когда и 8 - хватит с головой? Не хватает! А после запуска таких монстров, как Android Studio, обычный блокнот кажется вполне подходящим редактором для кросс-платформенной разработки.

Их сказанного выше выбор QML в качестве кросс-платформенного интерфейса видится весьма перспективным. Базовый набор элементов UI позволяет использовать его как в мобильной, так и настольной среде, а поддержка Material Design означает то, что всё будет выглядеть свежо и гибко конфигурируемым. Позволит ли это использовать один код для настольной и мобильной среды? Нет! Это невозможно по причине физических характеристик разных устройств отображения данных. Можно, конечно, использовать масштабируемый интерфейс, но это приведёт к проигрышу и в удобстве работы, и в функциональности. Адаптивный дизайн - это необходимое, но недостаточное условие для получения удобного в использовании интерфейса. Здесь требуется также адаптация и функциональной части. Преимущество QML как раз и состоит в том, что адаптацию интерфейса и функциональности можно произвести в рамках одной технологии - QML. Невозможно при помощи одного инструмента решить любую задачу, но, если задачу качественно можно решить при помощи одного инструмента, то зачем для этого использовать 5?

Для отображения qml-файлов в разных операционных системах и устройствах можно использовать:

1. Браузер
2. Сервис

Создание полноценного браузера QML является непростой, да и не нужной работой. Но простая версия и использование этого слова позволяет концептуально расширить область использования QML - приложения, web-приложения, qml-страницы и др. ( web + интерфейс на qml). Проигрыватель qml-сцен (qmlscene) также звучит красиво, но потенциал технологии выходит далеко за рамки ассоциации с мультимедиа.

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