примеры таких разработок уже есть в широком доступе, и многие видели сами, что в итоге получилось.
Я видел только Slack и Visual Studio Code. Оба кажутся вполне годными продуктами, ни там, ни там как-то вообще не ощущаешь, что ты на самом деле работаешь внутри браузера.
Возможно, я не знаю чего-то существенного про Qt и QML. Но, если немножечко абстрагироваться от вашей поправки «огромный опыт в кроссплатформенности» — которая мне кажется, скорее, частным случаем, чем неким «общим местом» в современной индустрии разработки ПО, то выбор не так уж и очевиден — в первую очередь, с точки зрения стоимости разработки и доступности человеческих ресурсов.
C++ — отличный язык. Но, кроме того, что порог входа в C++ высокий сам по себе, в случае Qt добавляется необходимость хорошо понимать философию и принципы построения этого фреймворка. Быстро ли вы сможете нанять «с улицы» человека, который действительно является высококлассным спецом в C++ (а этот язык, как мы знаем, ошибок не прощает), и ещё и владеет Qt на должном уровне? И какую зарплату захочет специалист такого уровня? :)
А вот людей, знающих JavaScript и работу с браузерным DOM — на рынке гораздо больше, ибо фронтенд — это «стильно, модно, молодёжно». Осилить азы NodeJS и специфичные для nw.js / Electron API — для фронт-ендера раз плюнуть. «Выстрелить себе в ногу» в JS тоже, конечно, можно, но уже гораздо сложнее, чем в C++. В итоге, имеем гораздо бОльший «фактор автобуса» и более дешёвую стоимость разработки. Profit.
P.S. Да, я прекрасно понимаю, что есть ниши сложных и требовательных десктоп-приложений, в которых даже и думать не стоит о чём-то подобном nw.js или Electron. Поэтому, если вы пишете «убийцу Photoshop» или ПО для нелинейного видеомонтажа — тут, без сомнения, C++ и Qt будут правильным (и, наверное, единственным) выбором. С другой стороны, есть множество ниш гораздо менее требовательных — те же мессенджеры, казуальные игры, агрегаторы новостей — где написать быстро и дешёво, с точки зрения бизнеса, гораздо важнее, чем идеально вылизывать производительность и потребление памяти. И вот здесь подобные технологии «заходят» очень хорошо.
Например, в случае, когда нужно сделать десктоп и мобильное приложения, логика взаимодействия с сервером в которых совершенно одинаковая — в таком случае, удобно один раз написать эту логику на JavaScript и использовать как в nw.js / Electron, так и в React Native.
Могу ошибаться, но, припоминаю, что в старых ПК (поколения 286-386) на материнских платах использовались довольно типовые чипы, трудность доставания которых будет соизмерима с трудностью достать, например, процессор 6502, применявшийся в Commodore, или периферию к нему.
Заказные СБИС, содержавшие в себе чипсет целиком или его бОльшую часть, появились, по-моему, уже в материнских платах для 486 и выше. Вот там — да, только долгий и утомительный поиск живого «донора».
Любопытно, почему — ведь плотность и сложность монтажа там была заметно меньше, чем в совремеменных материнских платах. А, между тем, умельцы вполне перепаивают всякие там «южные мосты» и, тем более, конденсаторы фильтров питания на современных материнках.
Минусовал не я, но так уж случилось, что я имел некое отношение к разработке экосистемы вокруг RhoMobile. Было это года 3-4 назад, и тогда даже простенькие приложения на этой платформе, увы, безбожно тормозили на (тогда) не самом бюджетном Galaxy S4 Mini.
Возможно, с тех пор интерпретатор Ruby под Android был сильно оптимизирован, но, в целом, у меня точно возникли бы вопросы о сравнении производительности Ruby и JavaScript движков на мобильных устройствах. Последние очень сильно оптимизируются под ARM платформу. Что в этом плане происходит в Ruby сообществе — мне сложно сказать.
Здесь важно понимать, что мы считаем «нативной производительностью». Мне кажется, существенной разницы между, например, декларативной разметкой в WPF или Qt Quick, и, по сути, такой же декларативной разметкой в HTML5/CSS3, не будет. Так как, и в том, и в другом случае сама отрисовка будет производиться средствами GPU. По крайней мере, в WPF это точно так — насчёт Qt не уверен.
Если же мы говорим о «классических» элементах управления Windows, то тут возникает другой вопрос — много ли найдётся желающих пользоваться фреймворком, который предоставляет весьма узкие возможности для творчества в плане внешнего вида пользовательского интерфейса. Да, разумеется, есть subclassing, во только он подразумевает отрисовку средствами GDI, которое, если мне не изменяет склероз, не очень «дружит» с аппаратным ускорением графики.
Из моих воспоминаний, в те времена многие FIDOшники очень любили OS/2 именно потому, что она позволяла запускать сразу несколько DOS программ (а именно — FIDOшных утилит) в режиме многозадачности. И эмуляция реального режима virtual 8086 там была, как раз, сделана с толком и растановкой, и работала гораздо стабильнее, чем имевшиеся тогда DOS extenders типа desqview.
Я видел только Slack и Visual Studio Code. Оба кажутся вполне годными продуктами, ни там, ни там как-то вообще не ощущаешь, что ты на самом деле работаешь внутри браузера.
C++ — отличный язык. Но, кроме того, что порог входа в C++ высокий сам по себе, в случае Qt добавляется необходимость хорошо понимать философию и принципы построения этого фреймворка. Быстро ли вы сможете нанять «с улицы» человека, который действительно является высококлассным спецом в C++ (а этот язык, как мы знаем, ошибок не прощает), и ещё и владеет Qt на должном уровне? И какую зарплату захочет специалист такого уровня? :)
А вот людей, знающих JavaScript и работу с браузерным DOM — на рынке гораздо больше, ибо фронтенд — это «стильно, модно, молодёжно». Осилить азы NodeJS и специфичные для nw.js / Electron API — для фронт-ендера раз плюнуть. «Выстрелить себе в ногу» в JS тоже, конечно, можно, но уже гораздо сложнее, чем в C++. В итоге, имеем гораздо бОльший «фактор автобуса» и более дешёвую стоимость разработки. Profit.
P.S. Да, я прекрасно понимаю, что есть ниши сложных и требовательных десктоп-приложений, в которых даже и думать не стоит о чём-то подобном nw.js или Electron. Поэтому, если вы пишете «убийцу Photoshop» или ПО для нелинейного видеомонтажа — тут, без сомнения, C++ и Qt будут правильным (и, наверное, единственным) выбором. С другой стороны, есть множество ниш гораздо менее требовательных — те же мессенджеры, казуальные игры, агрегаторы новостей — где написать быстро и дешёво, с точки зрения бизнеса, гораздо важнее, чем идеально вылизывать производительность и потребление памяти. И вот здесь подобные технологии «заходят» очень хорошо.
Заказные СБИС, содержавшие в себе чипсет целиком или его бОльшую часть, появились, по-моему, уже в материнских платах для 486 и выше. Вот там — да, только долгий и утомительный поиск живого «донора».
Любопытно, почему — ведь плотность и сложность монтажа там была заметно меньше, чем в совремеменных материнских платах. А, между тем, умельцы вполне перепаивают всякие там «южные мосты» и, тем более, конденсаторы фильтров питания на современных материнках.
Возможно, с тех пор интерпретатор Ruby под Android был сильно оптимизирован, но, в целом, у меня точно возникли бы вопросы о сравнении производительности Ruby и JavaScript движков на мобильных устройствах. Последние очень сильно оптимизируются под ARM платформу. Что в этом плане происходит в Ruby сообществе — мне сложно сказать.
Если же мы говорим о «классических» элементах управления Windows, то тут возникает другой вопрос — много ли найдётся желающих пользоваться фреймворком, который предоставляет весьма узкие возможности для творчества в плане внешнего вида пользовательского интерфейса. Да, разумеется, есть subclassing, во только он подразумевает отрисовку средствами GDI, которое, если мне не изменяет склероз, не очень «дружит» с аппаратным ускорением графики.