HTML стал для нас совершенно естественным способом взаимодействия с аудиторией в интернете. И мы уже даже не задумываемся над тем, так ли он удобен на самом деле, возможны ли более современные и удобные альтернативы? И в то же время мы так или иначе испытываем недовольство от использования HTML приложений, зачастую успокаивая себя мантрой: «Ну это же HTML, что от него ожидать?». Попытке решить эту проблему и найти альтернативу привычному HTML и посвящена эта статья.
А вы любите HTML? Возможно, вы его неистовый поклонник? Тогда вам лучше не читать эту статью – дальше будет больно!
Лично я так или иначе работаю с HTML с самого его начала. Я помню первые HTML страницы в интернете, которые представляли собой исключительно текстовый документ, картинки в котором были лишь иллюстрацией к тексту, но никак не элементами графического оформления страниц. Затем отдельные чудаки придумали делать на этих страницах «дизайн». Для технических специалистов того времени это было дикостью, зачем добавлять к информации ненужные, отвлекающие украшательства, которые, ко всему прочему, ещё и жутко тормозят загрузку страницы, ведь интернет в то время работал на модемах и был медленным. Однако чудаки были упорными и, после некоторого периода бесплатных «дизайнов», им наконец удалось начать продавать свои творения бизнесменам различного уровня и толка. Это и положило начало тому интернету, который мы знаем сейчас, где полно аляповатых сайтов и где до сих пор особо одарённые компании соревнуются в способности создать наиболее навороченный дизайн, обвешанный огромными панорамами или, ещё хуже, фоновыми видео. Но речь не об этом.
Как я могу вспомнить, с самого начала «дизайн» в HTML был в первую очередь борьбой за то, чтобы впихнуть творческую фантазию в рамки достаточно скудных возможностей HTML, который не был предназначен для художественного оформления страниц. Только спустя годы в HTML стали появляться всё новые и новые опции, позволяющие хоть как-то примирить творчество чудаков с суровой цифровой реальностью. Наблюдать со стороны за этим было забавно: никогда не оставляло ощущение, что на старую, ржавую садовую тележку пытаются прикрутить то колеса от жигулей, то штурвал от Ту-154. Тем не менее, много лет спустя HTML превратился в инструмент, на котором сейчас делают уже вполне серьёзные вещи. Впрочем, «садовая тележка» (DOM) все ещё проглядывает за ворохом модных фич. Отдельно стоит упомянуть инпуты, кастомизация которых в большинстве случаев сводится к тому, что нативные HTML input прячутся и вместо них показываются созданные вручную из HTML тегов и стилей. Конечно, работать со всем этим было неудобно и весьма трудозатратно, поэтому начали появляться различные JS фреймворки, пытающиеся хоть как-то компенсировать кривизну и неудобство HTML. Хорошо помню первые версии jQuery, который стал уже не модным, но до сих пор достаточно широко используется. Затем появились React, Angular, Vue (простите, если что-то пропустил). Всё это безусловно хорошие вещи. Только это всё ещё надстройка над той самой садовой тележкой, которая была создана более 30 лет назад совсем для других целей.
Думаю, у многих людей, как и у меня, частенько возникала мысль «как бы это всё заменить?». Как убрать садовую тележку и использовать вместо неё нормальный, комфортный и современный электропогрузчик? Кажется, что это совершенно нереально: большая аудитория, уже привыкшая работать с браузерами, которые не могут использовать ничего кроме HTML, огромное количество специалистов с наработанным годами и даже десятилетиями опытом. И главное — отсутствие ответа на вопрос: «а на что менять?!». Преодолеть всю эту инерцию и по сей день кажется невозможным. Однако это не значит, что не стоит и пытаться. С QML я столкнулся очень давно, пожалуй, более 10 лет назад. Его изящество и гибкость мне понравились с самого начала. Да, были моменты, которые в нем несколько озадачивали. Но в то время и QML был несколько другой, и весь фреймворк Qt, на котором он построен, был достаточно сырым. Со временем он развивался и проникал в реальные проекты, и эти проекты, в свою очередь, помогали ему меняться. Сейчас мало кто знает, но на QML реализована масса приложений, как под Windows или Android, так и особенно много под Linux. Во всех этих проектах QML скрыт внутри приложения, поэтому мы зачастую и не догадываемся, что это он. Но пользуемся и это не вызывает у нас проблем, эти приложения работают быстро, стабильно и надёжно.
Ещё раньше я задумался о том, почему Qt до сих пор не выпустил браузер с поддержкой QML, тем более что интеграция Chromium у них уже и так есть. Сейчас мне кажется, что все просто были заняты своими проектами и никому, за исключением отдельных ренегатов, это было не интересно. Тем не менее некоторое количество лет назад я уже задумывался о том, как это можно было бы сделать. Однако гибкость Qt фреймворка на тот момент не позволяла достаточно адаптировать QmlEngine для работы через Web, а у меня не было достаточно опыта и сил в C++, чтобы решить такую задачу. Но не так давно я взглянул на Qt снова и заметил, что задача уже не выглядит неразрешимой. При этом возможно победить и проблему с разграничением доступа из разных вкладок, и реализовать загрузку контента из Web. И вот тогда я взялся за работу. Первый прототип был написан на самом QML. И, эврика, он работал! Для загрузки контента был использован Loader QML Type, а для обычных HTML страниц (чтобы не лишать пользователя привычных сайтов) — QtWebEngine. Всё это вместе чудесно работало, но пока ещё оставались проблемы с безопасностью и контролем над средой со стороны браузера. Вдохновленный первым успехом, тогда я принялся уже за разработку полноценного браузера на C++/Qt.
Самое интересное
Теперь я готов представить вам работающий браузер, который умеет открывать не только HTML, но и QML страницы! Собственно, вот он: https://github.com/Toorion/qml-browser. Сейчас я ещё не рискну утверждать, что именно эта технология заменит давно морально устаревшие DOM + HTML, однако я могу с полной уверенностью заявить, что эра HTML подходит к концу. Нет, HTML не исчезнет как класс, но его заменит если не QML, то язык, более соответствующий принципам SOLID, DRY, YAGNI (шучу), приспособленный к динамическому контенту и взаимодействию с пользователем, а HTML останется для того, для чего его создавали с самого начала — размечать гипертекст. Очень надеюсь, что если QML и не завоюет Web в ближайшем будущем, то хотя бы станет тем первым камешком, который запустит лавину борьбы технологий за будущий Web 3, 4, 5.0. Сейчас тот знаменательный момент, когда вы можете либо примкнуть к этой борьбе, осваивая новые и интересные подходы, либо оказаться заваленными грядущей лавиной.
Теперь немного о самом QmlBrowser
Наверное, если бы я вам просто поведал о новом браузере, пусть даже с более удобным и производительным языком (подробное сравнения QML и HTML можно найти здесь: White paper: Qt vs HTML5 #1 Practical Comparison), вряд ли бы вы всерьёз задумались над тем, чтобы использовать его в своей работе. Поэтому я дополню свой рассказ описанием нескольких фич, которые делает QmlBrowser уникальным, и завершу его описанием того, где уже сейчас этот браузер может вам пригодиться.
Неограниченное лимитами и гарантированное LocalStorage
В QmlBrowser вы можете загружать свои данные без всяких ограничений и полагаться на них не беспокоясь, что они будут постоянно исчезать. В дальнейшем планируется реализовать специальный менеджер, с помощью которого пользователь сможет следить за используемым пространством на диске.
Отсутствие Cookies
Больше вам не придётся спрашивать пользователя «принять» или «не принять» Cookies. Их в режиме QML просто нет (в HTML режиме все остаётся по-прежнему). «И какое же это улучшение?» – спросите вы. Но вернёмся на пункт выше: теперь вы можете хранить всю необходимую информацию в LocalStorage и передавать её на ваш сервер в запросе данных. В режиме QML пользовательский интерфейс и данные полностью отделены друг от друга. Для QML вам нет необходимости создавать страницы сайта на лету, в QML режиме ваш сайт – это аналог SPA в современном JS фреймворке.
Никаких CORS
QML режим в QmlBrowser просто не знает, что это такое. Ему это не нужно, безопасность обеспечивается совершенно иначе. Здесь просто нет возможности сделать HTML (QML) Injection. Возможно, рекламщики будут недовольны, ведь как теперь вставлять свою рекламу (здесь и монетизация будет работать по-другому, об этой большой теме я расскажу в отдельной статье), зато теперь вы можете обращаться к любым сайтам для запроса контента для пользователя, что открывает весьма широкие перспективы для творчества.
Поддержка работы с 3D – beta
QmlBrowser поддерживает работу с 3D на уровне движка. Вам не надо более разделять — сайт на HTML отдельно, а 3D на WebGL отдельно. В QML вы можете работать как с 2D, так и с 3D объектами и обеспечивать их взаимодействие друг с другом. Сейчас это уже отлично работает под Linux, под Windows пока есть нюансы.
SDAPPS (Serverless Decentralized Applications) – очень скоро
Уже совсем скоро QmlBrowser сможет не только заходить на сайты в интернете, но и устанавливать QML приложения из различных источников. Это может быть и репозиторий в git, и архив, расположенный на IPFS сервере. Откроются совершенно новые возможности для децентрализации, которая сейчас весьма условна. Конечно, сейчас много децентрализованных сетей, но какая же это децентрализация, если у всех есть единая точка входа — сервер, через который совершается взаимодействие с пользователем и который может быть взломан и использован злоумышленниками!
И, конечно, это не все, что будет реализовано в QmlBrowser. Вас ждут самые невероятные и неожиданные фичи, которые в перспективе перевернут весь Web! Но, конечно, это будет не сразу. А пока о том...
Как QmlBrowser можно применять уже сейчас
Полагаю, было бы весьма странным призывать вас прямо сейчас создавать QML сайты для широкой аудитории. Аудитория ничего не знает о QmlBrowser и вряд ли сразу кинется его использовать. Однако уже сейчас есть области, где QmlBrowser будет просто незаменим:
ERP решения
Для работы с данными QML подходит как никто другой. В сочетании с LocalStorage это вообще бомба. Вы можете обрабатывать большие формы а‑ля Excel, добавляя к ним онлайн проверки из базы, загружать отчёты пользователю, чтобы он мог гонять различные фильтры и сортировки, не заставляя сервер снова и снова отдавать отчёт частями, способными влезть на страницу браузера. И все это никуда не пропадает, если пользователь случайно нажал F5 или закрыл вкладку. При этом вы можете прямо в приложении запрашивать данные из интернета: курсы валют, макроэкономические показатели и прочее и прочее. Говорю со знанием дела — сам использую этот инструмент в работе.
Агрегаторы данных
Если раньше для агрегации данных необходимо было создавать сайт на сервере, который бы сам собирал данные из различных источников, то в QmlBrowser вы можете создать приложение, делающее это на стороне клиента. И вам уже не придётся придумывать как идентифицироваться от имени пользователя, хранить и обеспечивать безопасность его логинов и паролей и бороться с блокировкой IP вашего сервера, когда вы авторизуетесь на внешнем источнике от имени сразу нескольких пользователей. Например, вы можете сделать приложение, которое агрегирует данные с нескольких криптовалютных бирж и выводит совмещённый график цены и баланса пользователя, при этом пользовательские ключи для доступа к API будут храниться локально, что сразу сделает ваше приложение лидером среди всех известных Trading desk платформ, работающих через обычный браузер. Да и работать оно будет существенно быстрее.
Админки
Если вам нужно реализовать управление сайтом и хочется сделать это одновременно и просто, и функционально, то QmlBRowser теперь — это незаменимый инструмент! На сервере достаточно реализовать REST API, а уже интерфейс управления можно сделать на QML. Можете пока поверить на слово, а затем и убедиться самостоятельно — это будет самая удобная админка, которую вы когда‑либо делали. Да и скорость со стабильностью работы весьма порадуют администраторов, которые будут с ней взаимодействовать.
Конечно, я вряд ли смогу перечислить все доступные уже сейчас области применения QmlBrowser, но надеюсь, что конкретными примерами я показал вам направление мысли и, возможно, вы сами решите, как именно вы можете улучшить себе жизнь при помощи этого мощного инструмента. А я, со своей стороны, всегда буду рад фидбэку и пожеланиям по улучшению. И конечно, всегда буду рад единомышленникам, которые будут как разрабатывать новые инструменты при помощи QmlBrowser, так и непосредственно помогать с разработкой проекта.
Следите за новостями, ведь это только начало!
Телеграм: @QmlBrowser
Twitter (X): Toorion
Комментарии (33)
Vestibulator-1
21.09.2023 11:33-6Очередная хромо-поделка, выдал ошибку dxgi прямо из коробки, за болтовнёй лишённой смысла стоит желание собрать донатов с адептов секты новых технологий.
Какое 3D в вебе? Сейчас не 2005-й год когда даже из вьювера можно было в один клик публиковать интерактивные сцены. Второе нашествие велосипедописателей.
krenkus Автор
21.09.2023 11:33+2Вообще хром в данном браузере здесь лишь "для обратной совместимости". Жаль, что вы не уловили основной смысл.
Донаты, наверное, это хорошо, но я пока даже об этом не задумывался. Лично в моем плану - сначала сделать инстурмент действительно конкурентноспособный по функционалу, а уже только затем думать о монетизации.
С ошибкой dxgi конечно предстоит еще разбираться. Определенно она зависит от установленных именно у вас графических драйверов. Сейчас под Windows принудительно устанавливается Direct3D. Возможно, это не правильно. Я не специалист в Windows. Разработка велась под Linux и только потом докручивалась к Windows.Vestibulator-1
21.09.2023 11:33+2Люди ищут легковесный бравзер под вин хп, востребованность такого функционала будет расти с каждым днём. Ещё можно флеш вернуть, ибо не нашёл ни одного рабочего способа публикации в вэбгл и хтмл5.
dartraiden
21.09.2023 11:33Люди ищут легковесный бравзер под вин хп, востребованность такого функционала будет расти с каждым днём
Стоит учесть, что число людей, у которых такая потребность есть, с каждым днём сокращается. В итоге, потребность у условных полутора человек высоченная, но аудитория слишком мала.
demetr_ds
21.09.2023 11:33+5А за Вашей болтовней что-то стоит ? И да, благодаря таким как автор, как Вы его назвали "велосипедописатель" и рождается что-то новое.
Vestibulator-1
21.09.2023 11:33-7За это "что-то новое" принуждают платить тех кому это совершенно не нужно, ещё и на условиях отказа от ответственности. Что нового сделано айтишниками, 30 лет паразитируют на труде инженеров и клянчат финансирование, субсидии, инвестиции, преференции, льготы, а по факту даже нормальной экранной клавиатуры на ведроид создать не способны.
demetr_ds
21.09.2023 11:33Можно конкретики вместо лозунгов. Кто принуждает платить и за что ?
Vestibulator-1
21.09.2023 11:33Новые устройства на которых будут работать гламурные поделки раздают бесплатно?
ARad
21.09.2023 11:33А еще можно сделать на js и wasm просмотр qml файлов и можно использовать обычный браузер, как запасной вариант...
krenkus Автор
21.09.2023 11:33Да, такое уже есть. Но смысл как раз не в том, чтобы создавть монстра поверх DOM+HTML, а в том, чтобы вообще уйти от всего этого.
ARad
21.09.2023 11:33Чтобы что-то заменить, надо сначала создать мостик для плавного перехода.
krenkus Автор
21.09.2023 11:33Да, именно по этому пришлось в QmlBrowser встроить также и Chromium, благо для Qt это было не архисложно.
ARad
21.09.2023 11:33+1Разработчики не смогут заставить обычных интернет пользователей установить qml браузер. А если не будет qml пользователей, то разработчики не будут делать qml сайты. Да возможны исключения для корпоративных пользователей, но это крохи на фоне интернета. Получается замкнутый круг...
Если вы хотите расширить популярность вашего qml браузера, сначала будет полезно встроить его в стандартные html браузеры. Имея такой браузер внутри стандартного, разработчики смогут создавать qml сайты не опасаясь потерять пользователей. А дальше обычные пользователи qml сайтов поймут, что для скорости работы с qml нужно использовать специализированный qml браузер и начнется постепенное внедрение технологии и плавный переход... Я так это вижу.
Да чистый qml браузер тоже необходим сразу, но для плавного внедрения технологии среди разработчиков, а затем в массы, желательно также создавать qml браузер внутри стандартных браузеров.
krenkus Автор
21.09.2023 11:33Да, про пользователей и разработчиков именно так. И встройка через wasm уже есть, это Canonic - https://docs.page/canonic/canonic
Можете попробовать. Но тот, кто его писал, забросил проект и занялся другим - оптимизацией Chromium.
Я же решил пойти другим путем - создать инструмент для тех задач, которые нельзя сделать хорошо при помощи обычного браузера. Сам его использую для ERP решений и это вполне эффективно. В статье я попытался описать перечень задач, где именно он будет незаменим. Это конечно не вытеснит HTML бразуеры сейчас, но, как говорится "курочка по зернышку клюёт" )
codecity
21.09.2023 11:33+2Как вы, простой смертный, посмели ввязаться в войну браузеров, где сражаются лишь мегакорпорации с их многомиллиардными оборотами (прямо или опосредованно)? Да не то что ввязаться - как могли даже помыслить об этом?
Касательно самой идеи... Мне приходилось верстать на XAML и тоже во многом там проще, чем HTML+CSS того времени. Т.е. на XAML после 1 месяца мне было проще и понятнее, чем на HTML+CSS после нескольких лет работы с ним.
Но современный HTML+CSS уже не так уж плох на самом деле. Многие детские проблемы давно решены. То что синтаксис XML-based а не JSON-based - в принципе не критично - да можно сделать простую преобразовался XML->JSON и обратно, кста? Как вам идея?
Возможно ваша идея подошла бы как плагин к существующему браузеру, но не как отдельный браузер.
Как у вас с исполняемым кодом - используется WebAssembly или что-то подобное? На каких языках писать вместо JS?
krenkus Автор
21.09.2023 11:33Фокус QML, который меня до сих пор приводит в восторго: пишешь один раз компонент, а, замет, вставляешь его в любое место "сайта" буквально одной строкой:
MyComponent{}
как говоиться "вжух и готово".
В QML встроена таже JsEngine, что и в обычном браузере, возможно чуть более старой версии.
Писать, соответственно, можно на JavaScript. Сейчас я также допиливаю API так, чтобы основные JS фреймворки могли также работать с QML, как и с HTML.codecity
21.09.2023 11:33+2Писать, соответственно, можно на JavaScript.
А кроме JavaScript? Ведь это еще большая проблема, чем HTML+CSS.
krenkus Автор
21.09.2023 11:33+1Ну вообще это я хотел оставить "на сладкое" ) Да, я не вижу причин, почему современный браузер должен поддерживать только один язык. И конечно планирую добавить и другие. Но это не быстрая история. Например, уже сейчас есть QML модуль с поддержкой Python. Добавляй и работай. Но его пока нельзя включить в дистрибутив, так как с помощью этого модуля можно уже делать все, что угодно в операционной системе. А это не безопасно.
По этому кратко - да, планы добавить другие языки есть. По приоритетности, и когда именно, пока не могу ничего сказать.codecity
21.09.2023 11:33+1Но его пока нельзя включить в дистрибутив, так как с помощью этого модуля можно уже делать все, что угодно в операционной системе.
То есть вы просто ограничили модули, которые можно использовать?
По этому кратко - да, планы добавить другие языки есть.
А зачем усложнять - есть же WebAssembly?
krenkus Автор
21.09.2023 11:33Да, ограничил модели безопасными. В перспективе либо кастомизирую их, либо реализую механизм управления правами пользователем.
Да, есть WebAssembly, более того, есть Qt под WebAssembly. Но это решение очень тяжеловесное и весьма ограниченное. У меня есть решения аля TradingView для собственных нужд. Под WebAssembly оно работает ровно также, как TradingView - медленно и не надежно. Меня, как пользователя это не устроило от слова совсем. Это, кстати, и послужило толчком к реализации QmlBrowser. Это тот инструмент, который я в первую очередь использую сам для своей работы. И могу сказать, что запуск QML из OS совершенно нельзя сравнить с WebAssembly. Думаю, что по перспективам WebAssembly - это как Java Applets или Flash )codecity
21.09.2023 11:33Думаю, что по перспективам WebAssembly - это как Java Applets или Flash )
Зря вы так. WebAssembly - это не продукт жизнедеятельности конкретной корпорации - это W3C стандарт. Уже сейчас множество ЯП, тот же C, Rust, C++, C# - можно компилить в WebAssembly - все отлично работает во всех браузерах. Даже тот же QT поддерживает WebAssembly как один из вариантов.
krenkus Автор
21.09.2023 11:33+1Веротяно вы правы. Возможно имеет смысл делать не QmlBrowser, но WebAssembler браузер! ) Однако, одно другого не исключает. Запуск WebAssembler под DOM/HTML, имеет огромные накладные расходы. Традиционный браузер тяжеловесен и потребляет уйму ресурсов. И тут также необходим язык описания интерфейсов, так как многие языки их просто не имеют. С другой стороны, ничто не мешает интегрировать WebAssembler в QmlBrouser, расширив при этом, возможности исполняемых в нем языков и сделав инструмент гораздо более легким и быстрым, оставив больше ресурсов пользовательским приложениям.
Обязательно обдумаю эту идею, спасибо.
kit_oz
21.09.2023 11:33+3Идея интересная. Немного смущает некая «радикальность» в вопросах безопасности.
Кажется, что без ограничений на занимаемое в localStorage место, это самое место очень быстро закончится. Сейчас эти ограничения не позволяют web приложениям пухнуть так же сильно, как нативным. Если их снять - быстро получим кучи сайтов весом десятки мегабайт.
В чём проявляется «невозможность» инъекций? Из сети загружается тот же самый текст, который так же как и html можно подменить или модифицировать.
И как без кук передавать токен в запросах, выполняемых не из кода? Например, картинки на странице тоже могут быть закрыты за авторизацией.
krenkus Автор
21.09.2023 11:33+1Разумеется за LocalStorage нужно следить. Но как это сделано, например, на Android: Пользователь ставит программу, не ограничивая ее никак в потреблении ресурсов. Но есть "менеджер приложений", в котором можно посмотреть, кто сколько жрет ресурсов. Вот такой "менеджер приложения" я и планирую реализовать в браузере. А также и управления правами приложения, где, например, можно давать доступ к записи на диск - сейчас такой возможности просто нет из за угрозы безопасности.
По исключению "иньекция" - можно загружать страницы и скрипты только с текущего хоста, более того, все доступные файлы должны быть прописаны в qmldir.
Без кук - формируя токен самостоятельно и храня в базе (LocalStorage). Защищенные картинки можно загружать через JS, передавая все то, что необходимо для авторизации. Клас XMLHttpRequest в QML режиме также работает. Хотя, возможно в будущем, я его и заменю чем-то более удобным.
Zukomux
21.09.2023 11:33Очередная попытка натянуть сову на глобус. Они столько лет пытаются и свой браузер сделать и UI Kit, что это уже просто смешно. Писал я на qml. Соглашусь, для десктопа вполне приемлемо, но это все поделки и не более. Нормальной поддержки сертификатов нет, сервис воркеры работают с ограничениями и очень медленно. Пресловутый JsEngine это обрезанный функционал нормального браузерного API Если нужно что-то новое придется обновлять кор версию QT. Если ТС использует компоненты, то понятно что под капотом тем плюсовая обвязка, которая ещё и кроссплатформенно зависимая. Далее, нет поддержки сторонних js библиотек. Все ошибки браузера вы должны обрабатывать ручками на тех же плюсах. А так да, вещь хорошая.
krenkus Автор
21.09.2023 11:33Верно говорите, в основе обвязка на C++. Кросплатформенность, при этом, обеспечена фреймворком Qt и на сегодняшний день она достаточно проработана. Методы Браузерного API я реализую уже на C++ своими руками.
Не совсем понял на счет сторонних библиотек JS - их просто нельзя загружать с других доменов, но кто мешает положить к себе и загружать со своего хоста?
Ошибки на старницах, да, перехватываются и выводятся в консоль пользователя. Она пока не такая продвинутая, как у Chromium конечно, но вполне позволяет работать.
В целом конечно, работы еще много и, как я и написал в статье, пока это только начало, пока можно использовать этот инструмент лишь в ограниченных проектах. Ну, по моей собственной практике, в рамках таких проектов это отлично показавший себя инструмент!Zukomux
21.09.2023 11:33Ну так область-то применения этого браузера какая? Когда мы продукт разрабатывали, он нам нужен был чтобы в толстом клиенте веб страницы поднимать - так проще было функционал развивать. Но это только десктоп, для всего остального есть нативный хром. К чему я это говорю, что за ним сомнительное будущее, извините лично мое мнение. Мы уже наелись с ним, не говоря уже о том, что если надо открыть несколько окон, то это отдельные процессы, а не отдельные вкладки...
krenkus Автор
21.09.2023 11:33Область применения, скорее, такая же, как и у толстых клиентов, да. По крайне мере я сам его именно так и применяю. Мне это экономит массу времени и сил, чтобы не делать SPA на React, например.
Пока десктоп, однако технически ничто не мешает портировать это и под мобильники. Qt уже отлично с этим может справиться. Но для меня это цель из будущего.
На счет нескольких окон, то нет, это не обязательно. В QML можно открыть окно прямо из одного инстанса QMLEngine, в рамках одного процесса. В QmlBrowser это реализованно. Ровно как и открытие изолированных по контексту вкладок.
robertd
Вы бы фактических примеров использования накидали, с картинками, разбавив вводные
krenkus Автор
Да, мое упущение. Вот коллекция примеров, адаптированных именно под браузер.
https://github.com/Toorion/qml-browser-demo
Также ссылка на страницу с опубликованными примерами есть на странице в репе.