Как стать автором
Обновить

Комментарии 140

Я писал на qml еще до появления react/react-native. Сейчас пишу на react/react-native. Он лучше (ИМХО) и нанять разработчика интерфейса на react на порядок проще (самый большой минус вашего варианта).

Можно по пунктам?

Проведя несколько сотен собеседований у меня сложилось впечатление что qml разрабов на рынке достаточно-доступное количество.
Как правило это специалисты давно выросшие из С++ и пожелавшие двигаться дальше.

Действительно сложно оценить "успешность" решения, во всяком случае в ситуации, когда и браузер замещен, и приложение web не на привычных web-технологиях. Может рассмотреть в разрезе альтернативы электрон? Или ещё как-то, иначе не ясно на чем можно выиграть…

На производительности?

Qml — он вообще-то для другого. Да, он намного более эффективен, чем стандартный браузерный DOM, а тем более VDOM, но это скорее аналог XAML, чем HTML. В его движке не предусмотрена изоляция QML-кода от окружения, нопремер. Это чисто язык создания UI с возможностью лёгкой интеграции с пользовательскими C++ классами.

Qt Quick — для создания UI. QML — декларативный язык для чего угодно.

Ну с таким же успехом можно сказать, что и XAML «для чего угодно».
Я делал пару проектов в которых qml декларативно описывал бизнес-логику консольных демонов на с++, а qml компилятор устанавливал все взаимосвязи между объектами. Весьма гибко и удобно получилось.

А ещё qbs очень удобная штука была для конфигурации сборки на QML.

Да, qbs частично вдохновила. Но глянув их исходники, стало понятно почему её дорого поддерживать. Они маленько переинжененрили, у нас получилось проще реализовать.
Зачем это, когда Qt поддерживает WebAssembly?

WebAssembly это другая вещь. Это когда у вас есть код написанный на С++, вы его с помощью Emscripten портируете в WebAssembly, который потом в браузере с помощью HTML canvas рисует ваше приложение. Я же хочу другое, чтобы можно было на разных языках писать бэк, например на Java, Python, C#… и QML писать фронт. И чтобы это все работало.

Если 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


Ну размер хрома для винды ~130Mb, не думаю что размер это самая большая проблема.

НЛО прилетело и опубликовало эту надпись здесь

А сколько весит среднестатистический современный сайт на js-фреймворке?

НЛО прилетело и опубликовало эту надпись здесь
Я же хочу другое, чтобы можно было на разных языках писать бэк, например на 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…
Кроссплатформерность

Ну это то же самое, вид сбоку. Именно поэтому в него и пытаются втиснуть приложения..

Мне, как веб разработчику, в первую очередь было бы интересно увидеть как мог бы выглядеть полноценный сайт со всеми класическими штуками (адаптивность, ajax, css анимации, изменяющая цвет svg иконка по наведению курсора и прочее) на QML.
Дело в том, что последний раз когда я пытался что-то более менее симпотичное в Qt Designer (а не просто серый набор форм) я психанул до такой степени что в итоге все сделал на мерзком Electron-e.

Есть там и анимации, и наложение всяких масок на иконки (через QGraphicalEffects например), и все такое прочее. Только для именно целей "открыть у произвольного клиента в браузере" он все равно не годится, недостаточно изолирован от окружения.

Сайт и вебасемблере написать можно, меня интересует насколько это красиво компактно и читаемо получится. Насчёт молотка и гвоздей вы правы обсалютно, я именно так и подумал когда увидел эту статью (только в отношении qml)

Ну, это скорее иллюстрация человеческих привычек и специализации в одной области, с попыткой применять в другой ("когда в руках молоток, все проблемы кажутся гвоздями"). Возможно, при бОльшем опыте вне веба психануть бы не пришлось..

Совершенно верно. У меня код на qml льётся как песня. А на html никогда не получалось ничего путёвого. Видимо всё дело в абстракциях которыми мозг пытается отразить код.

Нельзя так просто взять и похоронить такие технологии, как html, css, js. Даже если это супер оптимизировано и удобно, но не принято большинством браузеров, разработчиками — оно само по себе мертворожденное

Можно, и пример тому — мобильные приложения.

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

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

Смотрите шире. Мобильные приложения — всего лишь возрождение идеи "нативные приложения". Если она оказывается достаточно удобной и популярной, никто не мешает продолжить это возрождение и на десктопах с ноутбуками.

Хм, может ещё создать какой-нибудь стор, откуда можно легко заинсталлить нужное приложение?
Ой, погодите-ка, да ведь АппСтор на маке и ВинСтор уже есть давно, только не нужны никому.


Потому и навязать что-то своё "супер-удобное" на готовой экосистеме не выйдет, нужно новое устройство, с блекджеком и собственными правилами.

Так может, всё дело в "стор", а не "репозиторий" (дистрибутива линукс) ?

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

Так в том и дело — мехнически перенося с одной платформы на другую, будет казаться дичь: перескакивая с мобильных на десктопы, надо сначала смотреть не на полный аналог = сторы, а на репозитории дистрибутивов. Ведь, например, Ubuntu мы будем считать достаточно популярной, не так ли?

Вообще, на самом деле, это уже дебри какие-то.
И у сайтов и у приложений есть свои, часто непересекающиеся ниши.
Если вернуться к QML из статьи, то невозможно подходом приложений заменить сайты. Хочется заменить сайты — значит это будет свой собственный браузер со своим собственным парсером. Никому не нужны тонны хлама на устройстве и на рабочем столе, каким бы эфемерным он ни был.
На настольных осях тоже можно установить приложения из разных мест, и мобильные приложения, если проводить аналогию, это как раз обычные приложения на настолках, которые и так себе вполне нормально нативно существуют.
Собственно, как и сами нативные мобильные приложения (на мобильных ведь тоже есть и веб и сайты).
То есть, тут скорее изначально вопрос, зачем сайты из одноразовой среды (да, сейчас уже не на 100%) переводить в многоразовую среду и почему (если "а почему бы и нет") они на сегодняшний день разделены.

А зачем ставить вопрос как "или — или"? Может, лучше стоит задуматься о том, что в Веб уже сколько лет тащат именно что приложения вместо сайтов, и потому-то он стал такой монструозный? Т.е. если разделять, то как раз имеет смысл, а сегодняшний уже сколько лет направлен на смешение.

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


сегодняшний уже сколько лет направлен на смешение

Видимо, потому что есть противоположная статье тенденция — всё в облака, ещё когда хромбуки запускали и обещали, что все приложения можно будет запускать "прямо сейчас" без установки.
Почему оно не взлетело — это уже другой вопрос, но сейчас существует похожая тенденция с переносом игр на сервера, так что на клиент будет передаваться только картинка и не будет требовать мощного железа. Лично мне, обе эти тенденции ближе, чем "давайте всё нативно сделаем".

Игр? На сервера? Картинку? А законы физики они как обойти собрались?.. С остальными приложениями это тоже может являться фактором, вносящим свой вклад в "не взлетело".


Перспективна скорее тенденция из облаков в "рой", таки в нативную сторону.

О, примерно реинкарнация 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 файлами

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


Модель "репозиторий дистрибутива линукс, которому я доверяю", всё-таки проще.

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

Тоже самое можно сказать про qml в браузере — ещё один хак для нежелающих изучить нативные браузерные технологии html css и js

С чего это они вдруг "нативные"? Наоборот, это нагромождение слоев абстракций, вот Qt в статье — действительно нативный.

вот Qt в статье — действительно нативный.

QML код выполняется в QJSEngine, что не делает его нативным. Так же возникнет вопрос с производительностью.

Нет. Только JavaScript код выполняется в QJSEngine, но QML — это не только, и, я бы даже сказал, не столько JS. Собственно QML-объекты — это, как правило, QML-морды к обычным C++ классам, наследникам от QObject. То есть, например, Window — это QQuickWindow, любой Item — это QQuickItem, и так далее. Да, кое-что там будет исполняться в рамках QJSEngine, например, обработчики событий, если они написаны на JS, но в основном — нет.

Вы описали кнопочки и окошечки, но забыли про логику, которая пишется на JavaScript/ECMAScript.

Да нет, не забыл:
Да, кое-что там будет исполняться в рамках QJSEngine, например, обработчики событий, если они написаны на JS

Но это обычно довольно-таки высокоуровневый код. Более того, зачастую его количество можно сократить благодаря property bindings — вместо того, чтобы писать логику типа «если изменилось такое-то свойство у того объекта, то изменить такое-то свойство у сего объекта» их можно друг к другу просто прибиндить.

Как вы сделаете интернет магазин, на одних свойствах?

Интернет-магазин на QML я бы делать не стал, и я уже объяснил, почему :) Но если его таки делать на QML, то он бы содержал JS-кода куда меньше, чем реализации на всяких реактах с VDOM, да и работал бы побыстрее. Одна беда — несекурно. QML engine не имеет никакого понятия о cross domain security и так далее. И если учесть цели, с которыми он создавался, то ничего удивительного.
А я бы научился хорошо пользоваться тем что есть, и тут идеально круглые костыли одинаково вредны, называй их хоть Реактом, хоть QML.

Если он будет под AGPL, то можно объявить его доверенным и считать секурным %)

Под AGPL можно таки опубликовать одно, а на веб-сервере замутить немного другое :)

Снова попробуем отработанное в репозиториях дистрибутивов — подписанные версии?

Тогда зачем вообще веб-сервер, отдающий QML'ки? Один раз получил подписанный архив с QML-файлами из публичного репозитория и пользуйся. Только это по факту это ничем от standalone app не будет отличаться. Автор же предлагает отдавать QML'ки вместо HTML'ек, то есть грубо говоря перегенерировать QML при каждом запросе в зависимости от неких внешних данных, добавлять-убирать элементы и так далее. Как именно тут «подписанные версии» будут работать?

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

«Действительно нативный» — это wxWidgets.
Почему на Java?! До кучи тогда уж и backend на Qt — Qt Http Server. ;)

Кроме того ещё есть node.js, go и т.п.
>Безопасность. Сейчас она просто отсутствует. Можно сделать такую страничку, которая отформатирует жесткий диск.

Что за бред? WebAssembly же работает в защищённом изолированном окружении — sandbox. С каких пор доступ к диску разрешили?!

Скорее, "бредом" будет попытка назвать предложенное WebAssembly, потому что оно ни к нему никаким боком, да и собственно к вебу лишь похожесть "для начала"/простоты, от которой следовало бы отойти.

Ясно, не заметил, воспринял статью в контексте недавнего сообщения в блоге Qt:
www.qt.io/blog/qt-vs.-html-the-full-stack-comparison
Тогда непонятно вообще о чём статья?! Детский сад какой-то.
НЛО прилетело и опубликовало эту надпись здесь
Стало ясно, что функциональности гиперссылок мало

Встречая такие формулировки, всегда хочется спросить: кому стало ясно? кому мало?

Но и этого было мало, нужна была динамика, добавили JavaScript. Но на всем этом не очень удобно разрабатывать

Кому нужна была динамика?
«Опытный пользователь ПК», которому без подмигивающего смайла страшно и скучно нажимать кнопку в банк-клиенте, диктует направление развития технологии.
Вечно поминаемые в данном контексте (и, в общем, всуе) «недопрограммисты, не потрудившиеся изучить технологию», несчастный PHP с якобы «чересчур низким» порогом вхождения – не причина «деградации», а её следствия.
Причина же заключается в том, что бизнесу нужны интуитивные на самом низком уровне интерфейсы, чтобы обеспечить максимальный охват аудитории; а такой аудитории совершенно не нужно лишних мозгодвижений, и летающие цветные кнопки принимаются ею на ура.
Замена одной технологии другой не изменит ничего (к тому же, в статье совершенно не видно даже формальных плюсов от этой замены: достаточно вспомнить, что «Hello world» в современном браузере выглядит как «Hello world», без единого тега).
Не говоря уже о «здоровой конкуренции» на рынке, когда от технологии, предназначенной совершенно не для этого, требуют «защиты авторских прав», наложений рекламы, слежения и прочих важных для бизнеса штук. В стандарте HTML5 более чем достаточно инструментов для динамики, и тем не менее попробуйте найти чистое использования тега video на популярном видеохостинге.

ИМХО, создание нового стандарта передачи действительно ИНФОРМАЦИИ (а не рекламы), технологически чистого, возможно, если этим будет заниматься крупная некоммерческая организация, также являющаяся единственным сертификантом браузеров. Но это, конечно, в другой реальности.

Вот и нашли причину всех бед — капитализм (с копирастией).


действительно ИНФОРМАЦИИ (а не рекламы), технологически чистого, возможно, если этим будет заниматься крупная некоммерческая организация, также являющаяся единственным сертификантом браузеров. Но это, конечно, в другой реальности.

Да почему бы и нет? Только, конечно, не браузеров, а таки выкинуть эти 26 лет нагромождений веба. Сейчас мессенджеры, например в лице Instant View в Telegram, делают слабую попытку шага в этом направлении — и как видно, даже такая мелочь принимается людьми на ура.

нашли причину всех бед — капитализм (с копирастией)


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

Виноват он в том, что он не стремится, чтобы они переставали быть неквалифицированными. Ну и нельзя говорить, что "практика показала" — для этого надо чтоб прошло лет примерно 200. Как при переходе от феодализма к капитализму.

Когда-то давно тоже приходили в голову похожие мысли о замене html на qml и собственном браузере для этого дела… Уф. Только как-то быстро осенило, что это полная чепуха :)
Но раз тут автор так сильно горит этой идеей, то предложу такой вариант: зачем делать браузер? Почему бы не сделать расширение для Хрома/Оперы, которое бы могло подключить библиотеки qt и отрисовать qml прямо в браузере? Ну как это делают всякие Ace Engine и ему подобные?

А смысл? Это уже проходили — Flash, Silverlight, Java-апплеты… как только делается попытка прилепить это к существующему вебу, оно тут же им заразится и умрёт.

НЛО прилетело и опубликовало эту надпись здесь

Когда-то у нас в Liri Browser возникала подобная идея. Был даже план по реализации изоляции страниц, но до исполнения, кажется, так никто и не добрался.

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

Спасибо за инфу, обязательно гляну flutter.

Ну не прямо движок хрома, а библиотеку для рисования 2D графики Skia, на которой Chrome, Android, Firefox и еще много чего написано.
Этот ваш qml хорошо, пока вы делаете hello world. Как только речь заходит о чемто сложнее кнопки с текстом, весь проект превращается в огромное сборище костылей и подпорок разного калибра.
Не хватает компонентов, которые уже есть в qt. Баги qml бэкендов фисят годами и всем плевать. Попытки увязать отображение с состоянием в нативном коде приводят к разрастанию костылей в нативном коде. И чтобы всем совсем стало весело, у нас теперь есть по две версии всех компонентов, каждая со своим API и костылями.
Смело! А если так, чтобы стандартные браузеры рендерили? Типа новый DSL на замену связке html+css+js…

И сразу на замену HTTP тоже. Oh, wait...

Зачем? Речь же идет о фрондендерах, а не разработчиках браузеров. Поэтому все протоколы, которые юзают основные браузеры, должны быть обязательно использованы (или же самые всеобъемлющие из них).

С чего это вдруг? На оба утверждения.

Миллениалы изобрели...

… изобрели golang
НЛО прилетело и опубликовало эту надпись здесь

В качестве бреда — можно скомпилировать плюсовый код в WASM, минимальными средствами вывести рендер на канвас и вот у вас тот же QML только в обычном браузере.

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

В комментарии выше маленько про другую безопасность. Учитывая, что предлагается убийца HTML, можно предполагать что при более широком распространении придется таки учитывать нюансы приватности данных. Так во время экспериментов с canvas в браузере его неоднократно выключали из-за того что существовали PoC решения, позволявшие иметь прямой доступ к железке. А оттуда уж кому-нибудь еще посигналить заразиться не такая большая проблема. Аналогично всякие инерфейсы, которые хотя бы через тот же WebIDL описываются имеют свои нюансы в плане безопасности, которые также надо учитывай. То есть проблемы типа утечки приватных данных пользователя и сбегание из песочницы, а не перехват трафика или компроментация пользовательских данных. Хотя, это тоже довольно интересный вопрос.

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

Зачем гонять код между клиентом и сервером, qml какой-то, когда есть json на котором можно описать весь интерфейс c данными (не разделяя!) и какое событие (callback) вызвать через websocket-rpc на сервере когда юзер пошевелится? в 5 раз проще и понятней будет и для клиента и для сервера.
Заголовок спойлера
[
    {
        "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 уже давно решены, таких как анимации, стили и переиспользуемые компоненты например.

Движок натянут сверху на flutter поэтому анимации темы есть готовые. Переиспользуемые компоненты — это все на сервер и к тому языку на котором он писан.

Интерфейс гонять вместе с данными нет никакого смысла. Данные постоянно обновляются, а интерфейс нет.

Если накладные расходы на интерфейс = 0, то почему нет. Получив данные можно рассчитать красивый интерфейс к ним на лету. обновив данные — то же. необычно, но когда-нить все gui так будут. Вот данные — нарисуй их мне максимально красиво на этом разрешении с таким dpi.

Что значит «накладные расходы равны нулю»? Если шлётся что-то дополнительное, значит, есть дополнительные накладные расходы.

Посмотрите пример json (Заголовок спойлера вверху). шлются данные которые нужно отобразить в интерфейсе. программа получив «думает» как их нарисовать оптимально на конкретном разрешении как программист-дизайнер и рисует. это вполне автоматизируемый процесс.

Я поддерживаю мечты (ключевое слово) автора, поскольку нет ничего грустнее, чемделать UI на HTML после QML. Естественным образом приходят мысли о том, каким прекрасным мог бы быть веб, если изначально его задумали бы динамичным, а не статическим. Какой простой и приятной могла бы быть разработка. И QML, по моим мнениям, вполне бы подошёл на роль основного языка. Но это утопия...

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

wasm вроде больше про замену JS, он разве решает проблемы HTML? Я лично считаю, что как ни прикрывай его листочками, запах останется (простите за такую аналогию).

Пока одни думают как выдавать 60fps в React, UI написанный на C++ и рисующий кнопочки в WebGL без проблем выдаёт эти 60 fps.

Это немного хардкорно как по мне. Но если задуматься, то это он есть, Qt — фреймворк на C++, который рисует alien-виджеты напрямую в opengl контекст.

Это немного хардкорно

Вовсе нет, если уже есть нативное приложение на C++.

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Не понял в чем проблема? В том, что весь UI/UX переделать или обеспечить чтение с экрана? У нас свой фремворк с поддержкой адаптивного дизайна, своей разметкой и т.д. Переделаем.

НЛО прилетело и опубликовало эту надпись здесь
UI написанный на C++ и рисующий кнопочки в WebGL без проблем выдаёт эти 60 fps

Нужна ссылка, без этого не считается

НЛО прилетело и опубликовало эту надпись здесь

Отправил в личку. 60 fps это ограничение браузера из-за vsync, на 144 герцовых должны выдавать больше.

Ха-ха, такая же идея приходила лет 10-12 назад после того, как прочитал про выполнение джаваскрипта в Qt. Тогда, правда, QML ещё не было, раздумывал над описанием UI в XML.

Почему именно Qml? Почему не Anko например? Как по мне анко очень похож на qml и при этом Kotlin уже есть в браузере. Осталось только портировать anko с андроида.
И какой браузер может выполнять Kotlin-код «as is»? Если вы имеете в виду через компиляцию Kotlin в WASM, то и в Qt есть WASM как build target. К тому же Qt не нужно «портировать с андроида», ибо это уже давно сделано.
Есть Kotlin/Native + WASM и есть Kotlin/JS на выбор.
Ну то есть он «есть в браузере» ровно в той же степени, что и Qt.
НЛО прилетело и опубликовало эту надпись здесь

Интересно, их сайт показывает на час больше, наверное совсем не админят со времён смен часового пояса (шутка)

Было даже развитие этой идет технология taxi. Отказ от html свой протокол передачи, отсутствие задержек.

Представляете, испокон веков так делают! И самые популярные из таких называются Chrome и Firefox!

Даю идеи бесплатно:


  1. Зачем было писать какой-то сайт-лоадер? Движок QML и так поддерживает network transparency и может грузить файлы прямо из сети.
  2. По-хорошему, конечно, нужно как минимум сделать свой фреймворк вместо Qt Quick и для начала запретить импортировать что-либо, кроме него.
  3. Нет никакого смысла держать два браузера. И пытаться встроить движок QML в существующие тоже. Вместо этого нужно делать наоборот: если урла указывает на QML, то грузить его, если же HTML, то можно этот HTML показывать в том же браузере через qml-ный WebView.

Спасибо за идеи )


Движок QML и так поддерживает network transparency

Да, я в статье касался этого. Интерфейс меняется редко, данные гораздо чаще, по этому можно сделать версионность и не грузить UI на каждый запрос.


По-хорошему, конечно, нужно как минимум сделать свой фреймворк

Да, так и нужно делать, но на это нужно время.


HTML показывать в том же браузере через qml-ный WebView.

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

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

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

Flash, серверлат (Silverlight), XBAP (Wpf Browser Application). Все это уже было. Идея ооооочень не нова, а точнее очень стара. В современном мире гораздо актуальнее становятся технологии тонких клиентов (а ля WebGL), о чем тут уже все, кому было не лень, поведали. Называть «браузером» простой лоадер QML я бы лично не отважился.
Очередной велосипед. Сочувсвтую. Как и любая новая технология, в этой тк же будут свои недостатки. Например, просто зашел в вики почиать о чем это, QML.… ребят вы серьезно? Кто такое писать будет? Тут у многих голова болит о каскадности и вложенности селекторов в CSS, а вы предлагаете использовать эту же проблему, но в js? Та ну нафиг!
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории