Что случилось с легковесными десктопными приложениями? История Electron

Почему «к сожалению»?

::> "Большая часть из списка вымершая, к сожалению"

::< "К сожалению нет "

Не увидел там подзаголовка "Dead projects"

А если поиском?:)

но уже у Nuklear и NanoGUI последние коммиты были 6 лет назад :(

Отсутствие комитов не означает что проект умер. Возможно он перешел в состояние только поддержки или контрибуторы его забросили. Тем не менее если он проверен в продакшене то вероятно его используют до сих пор. Наверно косвенный признак это наличие ишьюсов и ответов на них, также наличие активных форков. Еще есть такой момент что не все компании берущие какой-то open source продукт к себе в репозиторий возвращают что-то обратно в open source. Например на своей прошлой работе у нас был форк Qt-а со своими фиксами, патчами и дополнениями и там у людей даже мысли не было вернуть хотя бы фиксы обратно.

Что случилось с легковесными десктопными приложениями? История Electron

Большая часть из списка вымершая, к сожалению

К сожалению нет, вымершие живут в отдельной секции этого списка если Вы вдруг до него не спустились. В то время как выбор вполне не маленький даже из тех которые представлены в этом списке. К тому же это всего лишь один из списков, если поискать дальше то можно найти много больше. Я не знаю конечно какие у Вас требования к UI, но даже первой десятки должно хватить на вполне сложные проекты в плане UI. Не нравятся эти есть много других, например на Unreal Engine можно не только игры делать но и программы писать, их редактор как раз сделан на самом Unreal Engine. Есть другие варианты на других языках например на Lazarus/Free Pascal можно делать UI.

А действительно хорошие на go и rust есть?

https://slint.dev/ rust, https://github.com/cogentcore/core go

Что случилось с легковесными десктопными приложениями? История Electron

Тем не менее, по-настоящему кроссплатформенных фреймворков исчезающе мало, а «одноплатформенными» фреймворками по-прежнему продолжают пользоваться

Ну хорошо вот например только для C++ кроссплатформенные либы https://philippegroarke.com/posts/2018/c++_ui_solutions/ . А еще есть много на таких языках как go и rust, некоторые поддерживают даже мобильные платформы. Вы точно уверены что их "исчезающе мало"?

Что случилось с легковесными десктопными приложениями? История Electron

WebPack как бы не для решения проблемы кроссбоаузерности создан и используется.

Создавался не для этого, но сейчас используется в том числе и как раннер для инструментов типа AutoPrefixer, Babel и прочих которые решают эту проблему.

Под нативной разработкой вы подразумеваете разработку приложенмя под конкретную платформу, используя инструменты разработки конкретной платформы и её дизайн?

Насчет дизайна вопрос спорный но все остальное да. Вроде бы никто не мешает использовать кроссплатформенные инструменты, библиотеки, генераторы и прочее чтобы упростить себе жизнь работая больше чем на одной платформе. Приложения для Android разрабатывают не только на Java а для Windows не только на C++. Я бы даже сказал что для современных языков и фреймворков кроссплатформенность это обязательное требование, никому уже не нужен фреймворк работающий на одной платформе. Тулинг скрывает большую часть сложности на всех поддерживаемых платформах а генераторы и/или слой совместимости обеспечивает то самое пресловутое write once run everythere с оговорками естественно, но тут как бы и Electron делает тоже самое с оговорками.

Что случилось с легковесными десктопными приложениями? История Electron

Сильное заявление, и Вы конечно же можете его подтвердить ссылкой на бенчмарки?

Что случилось с легковесными десктопными приложениями? История Electron

Для большинства организаций скорость вывода продукта на рынок продолжает являться более важным аспектом, нежели его эффективность.

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

История Electron началась не так давно — всего лишь в 2013 году. Ещё до распространения техники поставки веб-приложений в десктопных обёртках разработчики, как правило, писали полностью отдельные нативные решения для каждой платформы. Нужна поддержка Mac? Пишите на Objective-C или Swift и разбирайтесь с Cocoa. Хотите поддержку Windows? Готовьтесь попотеть над C++, C# или .NET. Linux? Ещё веселее. У каждой платформы свои парадигмы UI, идиомы кода и пайплайны сборки, так что согласованное обслуживание мультиплатформенных приложений было болью. Многим командам в итоге приходилось обслуживать по две, а то и три базы кода, каждая из которых имела свои тонкие отличия.

Довольно странное утверждение, ведь разработка для Web-а, особенно в 2013 году тоже была далека от кросс/браузерности/совместимости, иначе не существовали бы такие инструменты как AutoPrefixer, Babel, WebPack и прочие. Уже несколько лет стал доминировать один браузер что по сути довольно сильно расхолодило многих разработчик. Но в 2013 были времена когда легко можно было разрабатывая на Chrome открыть свой сайт на Safari и обнаружить какой-нибудь странный баг и наоборот. Это еще не считая разных режимов (типа для людей с ограниченными возможностями и поддержки RTL), разных экранов и много чего еще. Моя мысль в том что для нативной разработки требуется примерно столько же (что тогда что сейчас) сколько и для разработки на Electron, просто многим не хочется что-то изучать когда можно использоваться уже знакомое, создается иллюзия что ты получишь что-то очень дешево. Но опять же Electron не "серебряная пуля" и если надо что-то сложнее чем просто функционал Web вряд ли это будет работа на вечерок.

Нам не нужны кодеры, нам нужны инженеры-разработчики

Если Вы в одиночку занимаетесь проектом?

Нам не нужны кодеры, нам нужны инженеры-разработчики

про t shaped шла же речь в посте, т.е. автор, как и я сам признается, что экспертом во всех сферах физически не стать, т.к. эксперты мы именно в разработке, но ввиду междисциплинарности профессии - надо не хуже джуна/мидла сферы, для которой пишешь ПО разбиратсья в предметке, иначе велика вероятность, что продукт будет сделан либо работает, но оч.кривой, либо сразу провальный, ибо делал тот, кто понятия не имеет что значит бизнес клининга

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

Нам не нужны кодеры, нам нужны инженеры-разработчики

В заказной разработке и в финтехе та же проблема, что вы описали, но даже там можно +- применить большую часть идей из статьи

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

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

Хорошо, Ваш клиент это китайская компания заказавшая приложение для торговли лапшой в Куньмине. Потом идет социальная сеть для уборщиков в США. Далее криптобиржа для австралийского клиента ну еще один маркетплейс для продажи кошерной пищи. Все проекты идут по 3-4 месяца т.е. условно через полторагода Вы бы разбирались в куньминской лапше, как работает рынок клининга в США, стали криптаном и естественно знатоком кошерной пище? Я думаю нет, Вы максимум что приобрели бы знания принесенные Вам через тз и/или общение с заказчиком и дополненные гуглингом.

Нам не нужны кодеры, нам нужны инженеры-разработчики

собираются на недельку и вместе разбирают работу продукта на реальных задачах

Это похоже на обычное совещание с заказчиком, просто выездное.

Нам не нужны кодеры, нам нужны инженеры-разработчики

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

Верное утверждение вот только стоит уточнить что все это делается только с технической стороны.

Крупные компании могут позволить создавать команды-конвейеры, в которых у работников узкие роли. Так и появились кодеры, математики-алгоритмисты, тестеры...

Они разделились не поэтому а потому что само по себе ПО стало намного сложнее и больше и один человек уже не может все это выполнять потому что сроки явно будут совсем другими. Когда-то средним проектом считался клиент банка и то из-за реализации модулей безопасности, сейчас клиент банка это мультиплатформенный клиент в котором можно и билеты на театр заказать и на самолет с синхронизацией между разными устройствами, а в последнее время еще и AI ассистентом. Если раньше клиентом банка мог действительно заниматься один программист то теперь как считаете все еще может?

В мелкой компании человек может исполнять все роли. Т.е. составить ТЗ, реализовать, а потом развернуть. И это не значит что у человека будет больше нагрузка. Наоборот может быть из-за небольшой нагрузки он может тянуть все и больше людей брать не нужно.

Нагрузка тут не причем, размер и сложность проекта на это влияют.

Очень плохо если программист не выходит в поле. Хотя бы в начале проект нужно побывать у заказчика и своими глазами увидеть контекст.

В большом количестве случаев это невозможно или даже бесполезно. Например Вы делаете систему для автоматизации больницы, Вы приехали в больницу и что Вы там узнали? Чтобы получить полный контекст чего-то Вам надо задержаться там надолго и "поработать" вместе с заказчиками. Но опять же даже если Вы побываете там в начале проекта это не гарантирует того что на объекте что-то поменяется через полгода или год когда проект уже будет на финальных стадия разработки. Именно поэтому есть аналитик который должен "кататься" часто к клиенту чтобы следить что там у него происходит.

Нам не нужны кодеры, нам нужны инженеры-разработчики

Я думаю проблема людей в финтехе в том что у них заказчик это они сами, заказчик банка это сам банк. Да у банка есть клиенты, но они жалуются работникам банка которые в свою очередь и являются заказчиками каких-то фич. Т.е. здесь заказчик и исполнитель это по сути коллеги работающие в одной организации. И да тут можно коммуницировать, обсуждать, "быть в теме всего" и т.п. Большинство работников "сидят" на работе по 5-10 лет и уже "свои в доску". В такой атмосфере Ваш стандарт может работать. А теперь посмотрим на другие области где заказчик это обычно внешнее лицо с непонятными целями, непонятной мотивацией и лицо это может быть как физическое одно лицо, так и юридическое лицо или группа лиц с которым если и есть связь но для принятия решений требует согласований неизвестной группой лиц на их стороне с которой у Вас нет четкой и всеобъемлющей связи и всеобъемлющего понимания того что они делают и зачем. К тому же сегодня команда делает мобильное приложение в медицинской сфере а через 4 месяца социальную сеть для уборщиков, знать глубоко каждую предметную область в таком темпе даже не сложно а невозможно. Поэтому и сложилось разделение которое Вы критикуете и предлагаете упразднить вот только такое если и возможно то только в Вашей отрасли и то не факт что везде.

QML: отличие оператора ":" Qt.binding от Binding

Сравнивается Binding и JS

В моих тестах есть и такое сравнение и разница в скорости смешная.

а в ссылке про это всё есть

По ссылке рассматривается узкий пример инициализации значения и 'за' и 'против' применения onCompleted вместо определения поля с дефолтным значением. Про биндинги там вообще ни слова нет, и кто из нас съезжает с темы?

Например выравнивание ширины ListView по макс элементу.

А как стали делать `без JS`?

У нас был деятель, который делал это через JS - уволили.

Огласите пожалуйста название Вашей компании чтобы всем точно знать куда идти работать не стоит. Там где легко увольняют за одно решение.

NDA

Мы находимся на техническом ресурсе, и если Вы хотите кому-то что-то доказать то доказывать надо, не поверите, пруфами, т.е. кодом, тестами и бенчмарками. До тех пор пока Вы их не предоставили все Ваши слова не более чем трёп.

QML: отличие оператора ":" Qt.binding от Binding

Нет, мы этого делать не будем, а просто прочитаем документацию

В моем бенчмарке исследуется вопрос производительности биндинга против присвоения через JS и C++, и Ваша ссылка вообще не имеет никакого отношения к нему ровно как и остальные две написанные в сообщении ниже.

 А по опыту выкидывание JS сокращало код в 2-3 раза минимум.

А функционал тоже выкидывался вместе с кодом?

Если логику держать в JS сразу возникают сложности с наследованием, декомпозицией, оптимизацией кода

агрегацией, конкатенацией, маршрутизацией... добавьте еще любые другие слова. Без примера кода это просто набор слов.

Т.к. сразу в новые или декомпозированные элементы нужно сразу тащить весь JS код.

Тоже неясно без кода ничего.

HTML совершенно отличный от QML - там нет биндингов и машины конечных состояний.

Биндинг это просто функция вместо значения которая вызывается когда надо получить значение, машины конечных состояний это функция-генератор которая нативно уже давно в любом JS рантайме поддерживается да и без нее это можно "за вечерок" реализовать если надо. QML использует JS движок из Chrome и заимствует огромное количество концепций из HTML, даже подмножество тегов HTML поддерживается в некоторых QML элементах. Поэтому "совершенно отличный" это преувеличение.

QML: отличие оператора ":" Qt.binding от Binding

JS будет ещё хуже работать вне биндингов, будет гораздо менее производительным и значительно ухудшит архитектуру и расширяемость

Хорошо сделаем синтетический тест на сравнение чтобы убедиться что JS "будет гораздо менее производительным". Использую Qt 6.6 на Intel Core i9x2 2.80г, память 16Гб. Сделал вот такой вот простенький пример для биндинга :

import QtQuick

Window {
    width: 640
    height: bindingItem.bindingValue
    visible: true
    title: qsTr("Hello World")

    QtObject {
        id: bindingItem
        property int bindingValue: 200
    }

    MouseArea {
        anchors.fill: parent
        onPressed: {
            for (let i = 0; i < 1000; i++) {
                bindingItem.bindingValue = bindingItem.bindingValue + 1;
            }
        }
    }
}

Запустил профайлинг 5 раз, средний результат на скриншоте (разница между тестами в несколько миллисекунд).

Идем далее и проверим кейс с присвоением этого же поля из скрипта переписав код так:

import QtQuick

Window {
    id: root
    width: 640
    height: 200
    visible: true
    title: qsTr("Hello World")

    MouseArea {
        anchors.fill: parent
        onPressed: {
            for (let i = 0; i < 1000; i++) {
                root.height = root.height + 1;
            }
        }
    }
}

Запустил профайлинг 5 раз, средний результат на скриншоте (разница между тестами в 10 миллисекунд).

Ну и последним проверим кейс с биндингом из С++:

import QtQuick
import TestBinding

Window {
    width: 640
    height: testCppBinding.bindingValue
    visible: true
    title: qsTr("Hello World")

    TestCppBinding {
        id: testCppBinding
    }

    MouseArea {
        anchors.fill: parent
        onPressed: {
            testCppBinding.changeBinding();
        }
    }
}

#ifndef TESTCPPBINDING_H
#define TESTCPPBINDING_H

#include <QObject>
#include <QQmlEngine>

class TestCppBinding : public QObject
{
    Q_OBJECT
    Q_PROPERTY(int bindingValue READ bindingValue WRITE setBindingValue NOTIFY bindingValueChanged FINAL)
    QML_ELEMENT
private:
    int m_bindingValue { 200 };

public:
    explicit TestCppBinding(QObject *parent = nullptr);

    int bindingValue() const noexcept { return m_bindingValue; }
    void setBindingValue(int bindingValue) {
        if (m_bindingValue == bindingValue) return;

        m_bindingValue = bindingValue;
        emit bindingValueChanged();
    }

    Q_INVOKABLE void changeBinding() {
        for (int i = 0; i < 1000; i++) {
            setBindingValue(m_bindingValue + 1);
        }
    }

signals:
    void bindingValueChanged();
};

#endif // TESTCPPBINDING_H

Запустил профайлинг 10 раз потому что был больший разброс, средний результат на скриншоте (разница между тестами в 100 миллисекунд).

Лишние 100 миллисекунд полагаю тратятся на клей между C++ и QML.

Результаты разные конечно но "гораздо менее производительным" какой-то из этих вариантов не стал точно.

Еще бы хотелось узнать от Вас примеры "ухудшит архитектуру и расширяемость".

QML декларативный, JS - процедурный

В соседнем лагере где HTML декларативный, JS - процедурный никого особо не смущает ничего :)

 По моему опыту злоупотребление JS происходит от непонимания QML.

Стоит уточнить только злоупотребление или просто употребление?

QML: отличие оператора ":" Qt.binding от Binding

Это неправильно! Происходит от незнания и непонимания QML. Это очень сильно ухудшает производительность, увеличивает тех долг, сильно усложняет сопровождение и поддержку, ухудшает расширяемость кода и т.п. Плавали - знаем! Поэтому подобную практику пресекли на корню.

Это зависит от того для чего Вы делаете и что Вы делаете. Большое количество биндингов и глубина цепочки этих самых биндингов также легко может стать причиной плохой производительности особенно на слабом железе поэтому не все так однозначно.

QML: отличие оператора ":" Qt.binding от Binding

Мы писали CodingStyle.md где явно не рекомендовали использовать JavaScript код вместо биндингов в т.ч.и потому

На самом деле это зависит от того как именно пишется приложение, если вся логика находиться в C++ то можно впринципе не использовать JavaScript а QML использовать как макет интерфейса. Но вот если приложение QML only или если у Вас дизайнеры/верстальщики участвуют в верстке QML такое вряд ли возможно, присвоение свойств через оператор = в JS функциях обычная практика для сложного дизайна.

readonly свойство с binding (присваиванием) решает эту проблему и запрещает менять биндинг.

Добавление readonly возможно только в своих компонентах, поэтому фундаментально это проблему не решит. К тому же никто не мешает через js менять не значение а сам binding который по сути является функцией Qt.binding .

В России к 2030 году планируют запустить защищённую промышленную сеть передачи данных

К 2030 году в России должна начать работать доверенная промышленная сеть (ДПС)

Аббревиатура явно не случайна...

Microsoft анонсировала новый инструмент для обнаружения и исправления галлюциногенного контента в результатах ИИ

Т.е. вместо траты усилий на то чтобы галлюцинирующего контента в ответах не было лучше сделаем средство которое будет проверять и исправлять постфактум.

Минцифры подготовило новые правила оказания услуг мобильной связи с ограничениями по выдаче сим-карт

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

И организаций таких конечно же будет одна на всю страну.