Комментарии 140
Я писал на qml еще до появления react/react-native. Сейчас пишу на react/react-native. Он лучше (ИМХО) и нанять разработчика интерфейса на react на порядок проще (самый большой минус вашего варианта).
Действительно сложно оценить "успешность" решения, во всяком случае в ситуации, когда и браузер замещен, и приложение web не на привычных web-технологиях. Может рассмотреть в разрезе альтернативы электрон? Или ещё как-то, иначе не ясно на чем можно выиграть…
Qml — он вообще-то для другого. Да, он намного более эффективен, чем стандартный браузерный DOM, а тем более VDOM, но это скорее аналог XAML, чем HTML. В его движке не предусмотрена изоляция QML-кода от окружения, нопремер. Это чисто язык создания UI с возможностью лёгкой интеграции с пользовательскими C++ классами.
Qt Quick — для создания UI. QML — декларативный язык для чего угодно.
WebAssembly это другая вещь. Это когда у вас есть код написанный на С++, вы его с помощью Emscripten портируете в WebAssembly, который потом в браузере с помощью HTML canvas рисует ваше приложение. Я же хочу другое, чтобы можно было на разных языках писать бэк, например на Java, Python, C#… и QML писать фронт. И чтобы это все работало.
В моей статье Qt Everywhere: WebAssembly и WebGL стриминг фронтенд написан на Qt+QML+JS, а бекенд на Go.
Если WebAssembly заиспользовать как вариант внедрения "моего браузера" в уже существующие браузеры, то да, мне кажется хорошая идея. Надо об этом подумать, спасибо.
Прям так не скажу про размер, большая часть это будут qt-шные либы.
Размер скомпилированных wasm-модулей из документации Qt.
Example
gzip
brotli
helloglwindow (QtCore + QtGui)
2.8M
2.1M
wiggly widget (QtCore + QtGui + QtWidgets)
4.3M
3.2M
SensorTag (QtCore + QtGui + QtWidgets + QtQuick + QtCharts)
8.6M
6.3M
Я же хочу другое, чтобы можно было на разных языках писать бэк, например на Java, Python, C#… и QML писать фронт.
Не проще qml в html конвертить?
А бэк и так на любом языке писать можно, или вы не в курсе?
> UI код клиента относительно простой. Например нам не нужно использовать какие-то CSS хаки, чтобы сделать 2 колонки одинаковой высоты.
Чтобы не было хаков для колонок, в css добавили flex и grid.
Даже если предположить, что ваша технология будет развиваться, то спустя годы вы придёте к тому же css, к копированию оттуда большинства свойств, их логики.
Вся эта сложность в css появилась не просто так, а для решения конкретных проблем.
Все эти проблемы возникнут и в вашей технологии, и для их решения вы точно так же будете вводить всё новые и новые усложнения.
Либо не будете, но тогда ваша технология будет со множеством ограничений, которые отсутствуют в классическом вебе.
> Разработку UI можно вести в графическом дизайнере Qt Creator
До тех пор, пока делается стандартный интерфейс из стандартных компонентов.
Потом добавляются собственные компоненты, потом их динамическое отображение, потом responsive вёрстка для разных размеров экранов, и в итоге визуальный редактор можно выкидывать на помойку — он больше мешает и ограничивает, чем помогает.
Визуальные редакторы не просто так не прижились в вебе.
> Предположительно скорость работы приложений будет гораздо выше чем HTML
Пока у вашей технологии будет отсутствовать безопасность и будет сильно ограничен набор фич по сравнению с вебом, то вполне вероятно, что да.
> Использование десктопных UI компонент
Спорный довод. В том же вебе практически всегда при разработке первое, что делают, это добавляют в свой стили какой-нибудь reset css, который убирает всю «платформенную» стилизацию браузерных компонентов.
Так же еще появляются вопросы на счёт кроссплатформенности и работе на мобильных устройствах.
Вся эта сложность в css появилась не просто так, а для решения конкретных проблем.
Все эти проблемы возникнут и в вашей технологии, и для их решения вы точно так же будете вводить всё новые и новые усложнения.
Без груза совместимости можно не решать проблемы 20-летней давности и не пытаться сделать космический корабль из трактора. html в современном вебе несет довольно малой полезной нагрузки, css по сути это конфигурация для заранее определенных шейдеров, но с помощью js из него пытаются сделать аналог программируемых шейдеров (что по сути стек Qt'шных технологий и делает), большинство из веб форматов не удобно для эффективных вычислений. Большинство из них в нынешнем вебе уже и неудобны для человека и генерируются каким-нибудь фреймворком. А в попытках решить специфичные проблемы, не нарушив совместмость, придумывается «13й стандарт» (webauth, webassembly, webgl, webrtc и т.п.), что только сильнее раздувает неэффективность и усложняет поддержку. Фактически у нас осталось 2,5 веб-движка, потому что остальные уже не тянут их поддержку (да и эти скрипят), но при этом и они работают далеко неэффективно, о чем и сами неоднократно упоминали и в гугле и в мозилле (конечно же обвиняя легаси).
Раньше у веба был ограниченный спектр задач, была простота, человекочитаемость и переносимость, но сейчас кроме распространнености у веба нет положительных качеств, а спектр решаемых задач существенно вырос, все из них решаются плохо.
Либо не будете, но тогда ваша технология будет со множеством ограничений, которые отсутствуют в классическом вебе.
Пока у вашей технологии будет отсутствовать безопасность и будет сильно ограничен набор фич по сравнению с вебом, то вполне вероятно, что да.
Веб 26 лет пытаются от ограничений избавить, получается все хуже и каких-то изменений в будущем не предвидется. Из-за такой изменчивости, легаси и раздутости периодически страдает и безопасность.
кроме распространнености у веба нет положительных качеств,
Кроссплатформерность. Же.
Меня больше всего добивает когда в пример ставится java, которая тоже кроссплатформерная, но десктопные приложухи на ней особой производительностью не страдают на удивление.
А уж делать «современный» UI на ней — идите нафиг, дайте мне лучше css…
Дело в том, что последний раз когда я пытался что-то более менее симпотичное в Qt Designer (а не просто серый набор форм) я психанул до такой степени что в итоге все сделал на мерзком Electron-e.
Есть там и анимации, и наложение всяких масок на иконки (через QGraphicalEffects например), и все такое прочее. Только для именно целей "открыть у произвольного клиента в браузере" он все равно не годится, недостаточно изолирован от окружения.
Ну, это скорее иллюстрация человеческих привычек и специализации в одной области, с попыткой применять в другой ("когда в руках молоток, все проблемы кажутся гвоздями"). Возможно, при бОльшем опыте вне веба психануть бы не пришлось..
Можно, и пример тому — мобильные приложения.
Ну так для этого нужно сначала выпустить устройство, которое заменит собой десктопы и ноутбуки. А потом уже пилить свой браузер на своих технологиях.
Смотрите шире. Мобильные приложения — всего лишь возрождение идеи "нативные приложения". Если она оказывается достаточно удобной и популярной, никто не мешает продолжить это возрождение и на десктопах с ноутбуками.
Хм, может ещё создать какой-нибудь стор, откуда можно легко заинсталлить нужное приложение?
Ой, погодите-ка, да ведь АппСтор на маке и ВинСтор уже есть давно, только не нужны никому.
Потому и навязать что-то своё "супер-удобное" на готовой экосистеме не выйдет, нужно новое устройство, с блекджеком и собственными правилами.
Так может, всё дело в "стор", а не "репозиторий" (дистрибутива линукс) ?
Ну Вы начали с мобильных приложений, я ими и ответил. Мобильные приложения никогда не распространялись через репозитории, и соотвественно, не могли быть достаточно удобными и популярными в таком виде.
Так в том и дело — мехнически перенося с одной платформы на другую, будет казаться дичь: перескакивая с мобильных на десктопы, надо сначала смотреть не на полный аналог = сторы, а на репозитории дистрибутивов. Ведь, например, Ubuntu мы будем считать достаточно популярной, не так ли?
Вообще, на самом деле, это уже дебри какие-то.
И у сайтов и у приложений есть свои, часто непересекающиеся ниши.
Если вернуться к QML из статьи, то невозможно подходом приложений заменить сайты. Хочется заменить сайты — значит это будет свой собственный браузер со своим собственным парсером. Никому не нужны тонны хлама на устройстве и на рабочем столе, каким бы эфемерным он ни был.
На настольных осях тоже можно установить приложения из разных мест, и мобильные приложения, если проводить аналогию, это как раз обычные приложения на настолках, которые и так себе вполне нормально нативно существуют.
Собственно, как и сами нативные мобильные приложения (на мобильных ведь тоже есть и веб и сайты).
То есть, тут скорее изначально вопрос, зачем сайты из одноразовой среды (да, сейчас уже не на 100%) переводить в многоразовую среду и почему (если "а почему бы и нет") они на сегодняшний день разделены.
А зачем ставить вопрос как "или — или"? Может, лучше стоит задуматься о том, что в Веб уже сколько лет тащат именно что приложения вместо сайтов, и потому-то он стал такой монструозный? Т.е. если разделять, то как раз имеет смысл, а сегодняшний уже сколько лет направлен на смешение.
Наверное потому что многоразовые веб приложения рано или поздно перейдут в мобильные приложения и настольные (да, в зависимости от бюджета, может не дальше электрона). А большие, сложные приложения на раз-в-месяц останутся в вебе и никто их себе ставить не будет.
сегодняшний уже сколько лет направлен на смешение
Видимо, потому что есть противоположная статье тенденция — всё в облака, ещё когда хромбуки запускали и обещали, что все приложения можно будет запускать "прямо сейчас" без установки.
Почему оно не взлетело — это уже другой вопрос, но сейчас существует похожая тенденция с переносом игр на сервера, так что на клиент будет передаваться только картинка и не будет требовать мощного железа. Лично мне, обе эти тенденции ближе, чем "давайте всё нативно сделаем".
Игр? На сервера? Картинку? А законы физики они как обойти собрались?.. С остальными приложениями это тоже может являться фактором, вносящим свой вклад в "не взлетело".
Перспективна скорее тенденция из облаков в "рой", таки в нативную сторону.
Вот вроде бы об этом: https://habr.com/ru/news/t/470111/
EDIT: про geforce now не знал, вот о чём изначально шла речь: https://habr.com/ru/news/t/471720/ (Google Stadia)
О, примерно реинкарнация GLan из нулевых, позже переименованного в Vedga, а потом почившего в бозе (во всяком случае, публично уже толком ничего не найти). Это был проект на Qt, еще в до QML-ные времена, позже ставший коммерческим, по удаленной отрисовке Qt-приложений. То есть, само приложение работало на сервере, а на клиент гонялась Qt-сериализация исключительно виджетов интерфейса и событий пользователя. Ну, примерно как если бы на локальный X11-сервер отображался интерфейс X-клиента с другой машины (только протокол менее многословный), если кто-то на Хабре еще помнит такое. Или как бухгалтеры работали с тонкого клиента в 1С, запущенном на мощном сервере, по rdesktop, только опять не сырая графика, конечно, а получше.
Соответственно, у этого варианта тоже есть ниша, где главный минус (безопасность) несущественен и даже может быть обращен в плюс — внутренние корпоративные приложения. Т.е. сервер юзера отличает по "логин-пароль", например, и дальше администратору/разработчику может даже удобнее, что нет ограничений "песочницы" JavaScript — машины скорее всего и так в домене или обладают иным способом повышенного доверия к серверу.
Только можно посоветовать побольше отойти от парадигмы Web/HTTP, чтобы использовать преимущества на полную катушку — не отдельные stateless HTTP-запросы, состояние в которых эмулируется архитектурным костылём в виде cookies, а полноценным постоянно живущим соединением, например. И вместо самого понятия URL и оверхеда POST-запросов — тоже взять что-то более подоходящее — скажем, модель RPC-запросов...
Правда придется подумать над протоколом, если захочется делать это не местечковым решением, а поддерживать более одного серверного языка, например...
Соответственно, у этого варианта тоже есть ниша, где главный минус (безопасность) несущественен...
Ну безопасности нет только потому, что она еще не реализована. Я не думаю что есть какие существенные проблемы это сделать.
Только можно посоветовать побольше отойти от парадигмы Web/HTTP ...
У меня похожие мысли. Мы не обязаны использовать только HTTP, можно придумать что-нибудь с сокетами, стримами, RPC, протобафом, переработать понятие URL, в общем взять все что будет нужно.
Я не думаю что есть какие существенные проблемы это сделать.
Если речь о "песочнице" типа JavaScript в браузере, то есть, и очень даже существенные. Он изначально создавался в обрезанном окружении, а Qt наоборот, нативная библиотека, которая не ограничивает никак.
Кто мешает нам, например, урезать доступное API и оставить только безопасные функции? Браузер имеет полный контроль над qml и js файлами
Тоже самое можно сказать про qml в браузере — ещё один хак для нежелающих изучить нативные браузерные технологии html css и js
С чего это они вдруг "нативные"? Наоборот, это нагромождение слоев абстракций, вот Qt в статье — действительно нативный.
Вы описали кнопочки и окошечки, но забыли про логику, которая пишется на JavaScript/ECMAScript.
Да, кое-что там будет исполняться в рамках QJSEngine, например, обработчики событий, если они написаны на JS
Но это обычно довольно-таки высокоуровневый код. Более того, зачастую его количество можно сократить благодаря property bindings — вместо того, чтобы писать логику типа «если изменилось такое-то свойство у того объекта, то изменить такое-то свойство у сего объекта» их можно друг к другу просто прибиндить.
Как вы сделаете интернет магазин, на одних свойствах?
Если он будет под AGPL, то можно объявить его доверенным и считать секурным %)
Снова попробуем отработанное в репозиториях дистрибутивов — подписанные версии?
Кроме того ещё есть node.js, go и т.п.
Что за бред? WebAssembly же работает в защищённом изолированном окружении — sandbox. С каких пор доступ к диску разрешили?!
Скорее, "бредом" будет попытка назвать предложенное WebAssembly, потому что оно ни к нему никаким боком, да и собственно к вебу лишь похожесть "для начала"/простоты, от которой следовало бы отойти.
www.qt.io/blog/qt-vs.-html-the-full-stack-comparison
Тогда непонятно вообще о чём статья?! Детский сад какой-то.
Стало ясно, что функциональности гиперссылок мало
Встречая такие формулировки, всегда хочется спросить: кому стало ясно? кому мало?
Но и этого было мало, нужна была динамика, добавили JavaScript. Но на всем этом не очень удобно разрабатывать
Кому нужна была динамика?
«Опытный пользователь ПК», которому без подмигивающего смайла страшно и скучно нажимать кнопку в банк-клиенте, диктует направление развития технологии.
Вечно поминаемые в данном контексте (и, в общем, всуе) «недопрограммисты, не потрудившиеся изучить технологию», несчастный PHP с якобы «чересчур низким» порогом вхождения – не причина «деградации», а её следствия.
Причина же заключается в том, что бизнесу нужны интуитивные на самом низком уровне интерфейсы, чтобы обеспечить максимальный охват аудитории; а такой аудитории совершенно не нужно лишних мозгодвижений, и летающие цветные кнопки принимаются ею на ура.
Замена одной технологии другой не изменит ничего (к тому же, в статье совершенно не видно даже формальных плюсов от этой замены: достаточно вспомнить, что «Hello world» в современном браузере выглядит как «Hello world», без единого тега).
Не говоря уже о «здоровой конкуренции» на рынке, когда от технологии, предназначенной совершенно не для этого, требуют «защиты авторских прав», наложений рекламы, слежения и прочих важных для бизнеса штук. В стандарте HTML5 более чем достаточно инструментов для динамики, и тем не менее попробуйте найти чистое использования тега video на популярном видеохостинге.
ИМХО, создание нового стандарта передачи действительно ИНФОРМАЦИИ (а не рекламы), технологически чистого, возможно, если этим будет заниматься крупная некоммерческая организация, также являющаяся единственным сертификантом браузеров. Но это, конечно, в другой реальности.
Вот и нашли причину всех бед — капитализм (с копирастией).
действительно ИНФОРМАЦИИ (а не рекламы), технологически чистого, возможно, если этим будет заниматься крупная некоммерческая организация, также являющаяся единственным сертификантом браузеров. Но это, конечно, в другой реальности.
Да почему бы и нет? Только, конечно, не браузеров, а таки выкинуть эти 26 лет нагромождений веба. Сейчас мессенджеры, например в лице Instant View в Telegram, делают слабую попытку шага в этом направлении — и как видно, даже такая мелочь принимается людьми на ура.
нашли причину всех бед — капитализм (с копирастией)
Ну, не совсем. Ресурсы по-прежнему ограничены, а значит, нужна система их распределения. Практика, которая критерий истины, показала, что лучше всех с этим справляется капитализм (с некоторыми социальными элементами, но тем не менее). Нравится нам это или нет, но это факт реальности.
В свою очередь, ту или иную систему можно построить лишь на некотором подходящем базисе. В целом, нельзя сказать, что именно капитализм виноват в том, что большинство потребителей-пользователей является абсолютно неквалифицированными. Мы имеем то, что может дать некий усреднённый член большинства.
Виноват он в том, что он не стремится, чтобы они переставали быть неквалифицированными. Ну и нельзя говорить, что "практика показала" — для этого надо чтоб прошло лет примерно 200. Как при переходе от феодализма к капитализму.
Когда-то давно тоже приходили в голову похожие мысли о замене html на qml и собственном браузере для этого дела… Уф. Только как-то быстро осенило, что это полная чепуха :)
Но раз тут автор так сильно горит этой идеей, то предложу такой вариант: зачем делать браузер? Почему бы не сделать расширение для Хрома/Оперы, которое бы могло подключить библиотеки qt и отрисовать qml прямо в браузере? Ну как это делают всякие Ace Engine и ему подобные?
Когда-то у нас в Liri Browser возникала подобная идея. Был даже план по реализации изоляции страниц, но до исполнения, кажется, так никто и не добрался.
Вы только что изобрели flutter. Его разработчики взяли движок хрома и выкинули из него html, оставив только рендер, который десяток лет оптимизировали по самые яйца.
Не хватает компонентов, которые уже есть в qt. Баги qml бэкендов фисят годами и всем плевать. Попытки увязать отображение с состоянием в нативном коде приводят к разрастанию костылей в нативном коде. И чтобы всем совсем стало весело, у нас теперь есть по две версии всех компонентов, каждая со своим API и костылями.
Миллениалы изобрели...
В качестве бреда — можно скомпилировать плюсовый код в WASM, минимальными средствами вывести рендер на канвас и вот у вас тот же QML только в обычном браузере.
В текущем варианте возникает сразу вопрос про безопасность всего этого QML. Инженеры писавшие текущие реализации долго стремились к изоляции всяких рантаймов — JS, canvas, css и вот это вот все. Шансы что все то же самое придется делать и с QML довольно велики.
Есть вариант, когда это не требуется, см. в https://habr.com/ru/post/473302/?reply_to=20813894#comment_20810708
В комментарии выше маленько про другую безопасность. Учитывая, что предлагается убийца HTML, можно предполагать что при более широком распространении придется таки учитывать нюансы приватности данных. Так во время экспериментов с canvas в браузере его неоднократно выключали из-за того что существовали PoC решения, позволявшие иметь прямой доступ к железке. А оттуда уж кому-нибудь еще посигналить заразиться не такая большая проблема. Аналогично всякие инерфейсы, которые хотя бы через тот же WebIDL описываются имеют свои нюансы в плане безопасности, которые также надо учитывай. То есть проблемы типа утечки приватных данных пользователя и сбегание из песочницы, а не перехват трафика или компроментация пользовательских данных. Хотя, это тоже довольно интересный вопрос.
[
{
"name": "Window",
"icon": "accessibility",
"childs": [
{
"name": "X Table",
"headers": [
"head1",
"head2",
"head3",
"head4"
],
"rows": [
[
"string1",
100.8,
true,
{
"icon": "alarm"
}
],
[
"string2",
200.8,
true,
{
"icon": "alarm"
}
],
[
"string3",
300.8,
false,
{
"icon": "alarm"
}
],
[
"string4",
400.8,
false,
{
"icon": "alarm"
}
]
],
"value": 2
,
"actions": {
"Remove": "remove",
"Edit": "edit"
}
}
]
},
{
"name": "Window 2",
"icon": "accessibility",
"childs": [
{
"name": "name",
"value": "no name"
},
{
"name": "Select",
"value": "val1",
"options": [
"val1",
"val2",
"val3"
]
},
{
"name": "Is mine",
"value": true
},
{
"name": "Y Table",
"headers": [
"head1",
"head2",
"head3",
"head4"
],
"rows": [
[
"string1",
100.8,
true,
{
"icon": "alarm"
}
],
[
"string2",
200.8,
true,
{
"icon": "alarm"
}
],
[
"string3",
300.8,
false,
{
"icon": "alarm"
}
],
[
"string4",
400.8,
false,
{
"icon": "alarm"
}
]
],
"value": [
2
],
"actions": {
"Remove": "remove",
"Edit": "edit"
}
}
]
}
]
Такой json ничем принципиально не лучше, чем QML, и требует во-первых, написания нового движка, во-вторых, решения множества задач, которые в QML уже давно решены, таких как анимации, стили и переиспользуемые компоненты например.
Интерфейс гонять вместе с данными нет никакого смысла. Данные постоянно обновляются, а интерфейс нет.
Что значит «накладные расходы равны нулю»? Если шлётся что-то дополнительное, значит, есть дополнительные накладные расходы.
Я поддерживаю мечты (ключевое слово) автора, поскольку нет ничего грустнее, чемделать UI на HTML после QML. Естественным образом приходят мысли о том, каким прекрасным мог бы быть веб, если изначально его задумали бы динамичным, а не статическим. Какой простой и приятной могла бы быть разработка. И QML, по моим мнениям, вполне бы подошёл на роль основного языка. Но это утопия...
Вообще мне кажется, что специальный фреймворк поверх wasm будет и быстрее и безопаснее, а еще нужно не забывать, что кроме людей странички еще поисковыми ботами индексируются.
И тут по видимому хорошо бы иметь api, через которое они могли бы взаимодействовать со страничкой, а не как сейчас.
wasm вроде больше про замену JS, он разве решает проблемы HTML? Я лично считаю, что как ни прикрывай его листочками, запах останется (простите за такую аналогию).
Это немного хардкорно как по мне. Но если задуматься, то это он есть, Qt — фреймворк на C++, который рисует alien-виджеты напрямую в opengl контекст.
P.S. Хотя да, Qt Multimedia на WASM target пока не поддерживается, наверное, Qt Speech тоже работать пока не будет.
Не понял в чем проблема? В том, что весь UI/UX переделать или обеспечить чтение с экрана? У нас свой фремворк с поддержкой адаптивного дизайна, своей разметкой и т.д. Переделаем.
UI написанный на C++ и рисующий кнопочки в WebGL без проблем выдаёт эти 60 fps
Нужна ссылка, без этого не считается
Ха-ха, такая же идея приходила лет 10-12 назад после того, как прочитал про выполнение джаваскрипта в Qt. Тогда, правда, QML ещё не было, раздумывал над описанием UI в XML.
Исполняемый код, в самом злодейском виде, да на клиенте? серьёзно?
Отсыпьте и мне )
Даю идеи бесплатно:
- Зачем было писать какой-то сайт-лоадер? Движок QML и так поддерживает network transparency и может грузить файлы прямо из сети.
- По-хорошему, конечно, нужно как минимум сделать свой фреймворк вместо Qt Quick и для начала запретить импортировать что-либо, кроме него.
- Нет никакого смысла держать два браузера. И пытаться встроить движок QML в существующие тоже. Вместо этого нужно делать наоборот: если урла указывает на QML, то грузить его, если же HTML, то можно этот HTML показывать в том же браузере через qml-ный WebView.
Спасибо за идеи )
Движок QML и так поддерживает network transparency
Да, я в статье касался этого. Интерфейс меняется редко, данные гораздо чаще, по этому можно сделать версионность и не грузить UI на каждый запрос.
По-хорошему, конечно, нужно как минимум сделать свой фреймворк
Да, так и нужно делать, но на это нужно время.
HTML показывать в том же браузере через qml-ный WebView.
Да, WebView можно использовать, но конкурировать с мэйнстримными браузерами тяжело. Видимо в начале нужно делать костыль через WebAssembly, и впихивать всю логику в уже существующие браузеры.
Да, WebView можно использовать, но конкурировать с мэйнстримными браузерами тяжело. Видимо в начале нужно делать костыль через WebAssembly, и впихивать всю логику в уже существующие браузеры.
Если бы я делал сайт на QML, то мой бэкенд выдавал бы чистый qml-файл для браузеров с его поддержкой и версию, скомпилированную в wasm для остальных.
wrong thread
Прощай HTML, привет QML