Electron 2.0

Ну хоть внешне.

годно и нужно

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

Node.js

Переход на GTK+ 3.

Ну когда же оно сдохнет?

Скорее его допилят до DE, чем ты дождешься смерти.

Тебя кто-то заставлял в программах на Qt или Delphi писать «всю логику в хэндлерах кнопок»?

так стандартная практика для делфистов

Я забросил наполовину написанное приложение для Андроида на Джаве и целиком переписал его на ReactNative исключительно и только ради того, чтобы не писать ТРИЖДЫ один и тот же код для трех разных платформ

Как твое приложение дружит с батарейкой? Собственно, батарейка и слабый проц есть бутылочное горлышко из-за чего я и отказался от динамики под мобайл.
У каждой платформы свои заморочки начиная от permissions и заканчивая native look and fell. Собственно, идея писать все для мобайл на JavaScript не нова, еще лет 6 назад были инструменты. Но столкнулись с двумя главными проблемами:

• Ты очень быстро сталкиваешься с чем то, что никак не реализуется вебом и приходится допиливать нативно под две платформы. И не один раз. В итоге на выходе жопа. Лучше бы сразу писали нативно. Возможно, они порешали какие то проблемы, но и сами ОС не стоят на месте. Вот вышли новые андроид и айось. Насколько велика вероятность, что их новые фичи уже включены в эти либы и без ошибок? Даже ксамарин, за которым деньги стоят и то хреновый хотя и чуть получше.
• Вторая проблема хуже. Ладно, ты порешал проблемы и получил рабочее приложение. И тут заказчик выдаёт тебе: слушай, а чего моё приложение выглядит как говно? Я тут скачал из аппстора пару похожих, так они красивые и работают быстро, и анимация, и скроллинг плавный. И ему плевать, что ты изначально предупреждал о этих проблемах.

нативные графические приложения

с помощью веб-технологий

/0

Как твое приложение дружит с батарейкой?

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

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

По этому при поиске компонентов для Реакта вынужден постоянно следить, что тот либо реализован на чистом JS (даже когда это выглядит неоправданным), либо имеет линки на обе платформы. Пока что собственноручно пришлось реализовывать ровно один компонент, потому как в Реакте внезапно отсутствуют биндинги на андроидовский Bitmap. И то, для iOS там пока что просто плейсхолдер, потому как до яблок я еще нескоро доберусь, так что тут тоже еще немало интересного меня ждет впереди.

И тут заказчик выдаёт тебе

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

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

При активной работе с аппой у тебя тупо будет жраться батарейка.

Но для чего-то более серьезного я тоже разумной альтернативы не вижу - либо тройная работа

Я уже писал, если не «привет, мир» упрешся в платформо-спецефичные вещи. Мобайл это такая штука, где дешевле сразу делать натив.

Тебя кто-то заставлял в программах на Qt или Delphi писать «всю логику в хэндлерах кнопок»?

так стандартная практика для делфистов

А что там за логика, пардон ?

В окне с настройками приложения это будет чтение/запись параметров из контролов текущей формы с передачей в объект, хранящий настройки приложения, но мы с контролами данного окна работаем, нам к ним обращаться, btnOk.OnClick обработчик сгенерен средой, вы предлагаете из него дергать код в другом месте, зачем ? чтобы что ? Я понимаю в языках где все эти OnClick РУКАМИ оформлять приходится и РУКАМИ же прибивать к событию, но там то выбора нет, и действительно получается мешанина вызова самих обработчиков и их содержимого. Но в делфи-то этой проблемы нет и даже при переименовании контрола/хэндлере среда сама поправит оформление.

В окне с работой с сущностью в BD это кончится либо простым вызовом Commit, либо его обертки, описанной в отдельном месте логикой работы с БД. Ой, не подходит - мы же тут логику из формы вынесли, т.к. она (логика) не локальная и локально ее при всем желании не запрешь.

Либо, если, например, при выборе счета нам нужно вывести остаток на lable в той же форме нужно по OnChange/OnExit/OnЧтоТамНамЛучшеПодходит дернуть код который сходит в БД и посчитает остаток, как вариант хряпой, но это явно функционал (добыть остаток по счету) требующий завернуть его в функцию которая параметром будет принимать id счета и возвращать сумму остатка. Т.е. это тоже локально не запрешь. Что там остается обработчик OnExit с единственной строкой laDebetRest.Caption:=AccLib.GetCurrentRestByAccount(cbDebitAccount.Text) ?

Т.е. все сводится к тому что мы не оформляем руками обработчики евентов, а такие ванлайнеры - это смешение бизнеслогики и евент хэндлеров которые в делфи вообще за код не воспринимают (ими среда занимается) ? - Да вы просто завидуете !

Кабутта через тыщу лет люди до електрона доростут

спалилась поняша: дискорд не умеет запускаться за секунду, но не потому что гуй, а потому, что сетевая часть тормозит и это не лечится

нет, именно из-за проблем с интерфейсом

почему-то до людей с трудом доходит простая мысль о том, что гуй написанный под 15 дюймов для устройств с 7-и дюймовыми экранами приходится полностью перепиливать и API тут не причём

закопайте node.js пока он к вам в холодильник или микроволновку не залез.

У сетевой части в дискорде действительно есть проблемы. Только я сомневаюсь в том, что тут виноват Электрон.

Когда перепишут Emacs под Electron?

Лучше бы наоборот.

Андроид замечательно работает на  7" и 15", там проблема была все таки с захваченным рынком корпорацией добра, по той же причине обосрались FirefoxOS, Ubuntu touch, и прочие поделки

критичные части которого можно вынести хоть на rust

это 95% всего продукта.

rust

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

сегфолтящееся черти-что

Я тебе покажу как на жабаскрипт сделать fatal error https://www.nczonline.net/blog/2009/05/19/javascript-stack-overflow-error/ Там и до сегфолта недалеко, так как стек располагается в оперативной памяти и он не резиновый.

всей логикой в хэндлерах кнопок

Так не делают уже лет 20-25. Или делают студенты на лабах.

но которым можно пользоваться без тошноты

Ты сейчас используешь браузер, который написан на вышеописанном тобой вещах.

Хм, а модули и обьекты в паскале зачем ?

Кстати, как раз навешивание на html тег js click всегда выглядело как костыль.

btnOk.OnClick обработчик сгенерен средой, вы предлагаете из него дергать код в другом месте, зачем ? чтобы что ?

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

Но в делфи-то этой проблемы нет и даже при переименовании контрола/хэндлере среда сама поправит оформление.

У делфистов стандартная практика смешать бизнес-логику и контролы. Например, примерно так формировать SQL:

Data.StdQry.SQL.Text:='UPDATE customer SET CUST_NAME='''+NameEd.Text +''', CUST_ADDRESS='''+AddrEd.Text+'''';

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

Тогда понятно почему пишут все более кривой и тяжелый софт, задача не в софте, а в выбивании бабок из лохов

А учитывая что вебщики самые низкоквалифицированные персонажи ставка на них может сыграть

А на JavaScript не получится с плавным скроллингом?

Угу, если посмотрите на не самый плохой фреймворк диджанго, вы найдете очень много общего с delphi

Хм, а модули и обьекты в паскале зачем ?

Кстати, про об'екты. Совершенно уродская модель использования виджетов, как компонент, которые надо где-то прописывать, чтобы они стали доступны. Т.е. по месту создать наследника, что-то с ним сделать и тут же забыть не получится из-за отсутствия нормального менеджера геометрии.

к счастью, я в вебню не лезу. У мну мобайл и электроника.

А на JavaScript не получится с плавным скроллингом?

Я тебе больше скажу, в андроид не всегда есть плавный скролинг. Из-за сборщика мусора. Кошерный скролинг в iOS.

А зачем делфи менеджер геометрии ? Там все элементы интерфейса стандарны и не требуют дизайна. Положил компонент на форму, навесил событие, готово. Никаких css, html, js, webpack, jquery, localstorage, и прочего

А зачем делфи менеджер геометрии ?

Во-первых, с менеджером геометрии кошерно создавать гуй в зависимости от ситуации, наследоваться и т.д.
Во-вторых, чтобы не было проблем в зависимости от изменения конфигурации экрана, например http://zarko-gajic.iz.hr/writing-and-enabling-delphi-application-to-support-h...

Если в делфе привязки в форме сделаны правильно, то проблем при изменении конфогурации не будет

Что касается high dpi, то это связано больше с os

Все гораздо проще, есть шутливый(но серьезный по сути) закон Вирта «Software is getting slower more rapidly than hardware becomes faster».

вебщики самые низкоквалифицированные персонажи

Принцип Шоу «Создайте систему, которой сможет воспользоваться даже дурак,и только дурак захочет ею пользоваться.»

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

Это как делать панельный дом и кирпичный дом. Для панельных домов много ума не надо. Свариваешь блоки и готово. Вся Россия, Украина и Беларусь и т.д. из таких домов. Плюс в том, что можно очень быстро строить целые города на пустом месте. Минус - вся страна представляет из себя гетто из бараков-скворещников.

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

Это дилема, когда мы хотим успростить инструмент, но в итоге упрощаем мозги кто этим инструментом будет пользоваться..

А вообще программистов таких и 20 лет было мало. Просто к плюсовикам и инженерам присоединились UI/UX и прочее прочее.

Електрон позволяет пилить JS кодерам на десктопе. GUI существовал и до электрона.

Cоздать калькулятор и на C++ можно в два клика.

Инвалидам да костыли :-)

Понимаешь вебщики ничего кроме своего Node.JS ничего не видели. Они думают что до их ноды, ничего существовало. Это потому что слишком специализированы. Им кажется что если это C то это уже плохо.

И пофиг что уже давно в Qt можно стили пилить, и что на Qml создавать калькулятор гораздо быстрее чем в ноде. И что сам Qt изначально под мобилки создавался. И пофиг что кроме Qt больше ничего не надо. Поставил С++ и Qt фреймверк. Тут тебе и сеть, тут тебе 3d графика, ту тебе виджеты, тут тебе потоки, тут тебе работа с китайскими символами, тут тебе мультитач, тут тебе композитор, туту тебе стили CSS. И кучу куча примеров. Копипасть себе на здоровье. Больше ничего устанавливать не надо.

sudo apt-get install qt-sdk и готово.

И пофиг что вот такой GUI получается у Autodesk Maya http://la.by/sites/default/files/soft/data-scene-management-tools-large-1152x...

И пофиг что Qt давно работает как на мобилках, как на десктопе, так и поверх игровых движков на примере Unigine https://developer.unigine.com/devlog/20090221-improved-data-streaming-keyline...

Вот это https://i.stack.imgur.com/4URoM.png Си + GTK c поддержкой питона

Вебщикам насрать что унылый дизайн ЭТО ПРОБЛЕМА ДИЗАЙНЕРОВ, А НЕ ПРОГРАММИСТОВ. У вебщиков виноват язык программирования Си. И почему-то не виноват язык программировнаия Rust, на котором нет родного достойного GUI.

Если в делфе привязки в форме сделаны правильно

1) А теперь сделай их в рантайме
2) «Если сделано правильно» не аргумент. Мало кто делает правильно.
В приведенном примере обвязки правильные, а получается фигня: http://zarko-gajic.iz.hr/wp/wp-content/uploads/2017/02/tcolorbox-highdpi.png

Что касается high dpi, то это связано больше с os

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

Чтобы отделить мух от котлет. Вся бизнес-логика должна быть вынесена в отдельный API.

Кому должна ? И ActionList инструмент, а не серебряная пуля. Местами он бывал и неудобен (а то и не применим, емнип, если, например, надо было разбирать кто там динамически создаваемый предок у Sender'a эвента и логика запиралась в форме).

У делфистов стандартная практика смешать бизнес-логику и контролы. Например, примерно так формировать SQL:

Для этого дата-контролы есть и емнип через параметры передавать можно. Я писал под Firebird/Oracle, не могу припомнить, чтобы такое могло понадобиться. А если такой код образовался, то его максимум можно запихнуть в обертку и легко переместить в другое место. Найти и отрефакторить такое быстро и не сложно. Вопрос - а всегда надо ли, если, например, приложение всего на пару десятков таблиц (правда тут непонятно зачем было так делать при наличии дата-контролов, может люди из других языков такие привычки принесли, из тех же с) ?

PSS: делфи хороший продукт была. Но порождало уродские практики программирования.

А в каком языке таких практик нет ? И неужели это хуже чем:

• бесконечная возня с указателями и приведениями типов в сях, где как ни старайся - годами потом будешь эти косяки в коде находить ?
• Тонны кода только чтобы открыть рот для чихания в яве ?
• Разные результаты сравнения в зависимости от типов данных в php ?

А сколько глюков и костылей городит народ из-за отсутствия жесткой типизации паскаля, VCL, RxTools, FBplus, ODAC, FastReport ?

В делфях руки выпрямить можно, а в сях куда указатели и приведения типов денешь ?

Кому должна ?

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

Для этого дата-контролы есть и емнип через параметры передавать можно.

для єтого нужно просто вызвать функцию с правильными параметрами. Но делфисты упорно смешивают запрос и EditText.

бесконечная возня с указателями

Уже давно придумали сборщики мусора (точнее ARC) даже для С.

тонны кода только чтобы открыть рот для чихания в яве ?

От не надо. Delphi тоже многословен. Но для него нет кучи языков, в отличие от jvm.

Во-первых, с менеджером геометрии кошерно создавать гуй в зависимости от ситуации, наследоваться и т.д.

Форма - класс. Наследуйся, никто не мешает.

Динамическое создание форм любых контролов и присвоение к ним евент хэндлеров вручную - сколько хочешь. У меня в приложениях всегда только главная форма создавалась, остальное из Application я вырезал и TMy100500Form.Create(Application) были только по мере необходимости и освобождал их OnClose - зачем ресурсы лишние есть?),

Во-вторых, чтобы не было проблем в зависимости от изменения конфигурации экрана,

Резиновые окна для разных разрешений не проблема - раскидываем панели на форму и выравниваем по сторонам - это не скейлится, alClient дает резиновую часть, внутрь него накидать панелей, повторить. Я бывало рисовал класс такого окна с частью контролов и не использовал напрямую, а наследовался от него. Разместить внутрь контролов для работы от 640*480 до FHD - не проблема. В крайнем случае, что-то можно и поскрулитть в 640, плюс есть констрейнты, а можно и в onResize контролы подвигать если что.

DPI - да, боль. Но когда я последний раз 15 лет назад ковырял делфи, эта боль была у всех поголовно. Да и сейчас этот вопрос не до конца решен, судя по тому что я наблюдаю в лине прямо сейчас на hidpi мониторе. Но тут все не на делфях писано.

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

Потому что вы сути упорно не замечаете. Люди начинают пользоваться электроном не потому, что любят убогонькие недоязычки и жор памяти. А потому, что весь прогресс в области UI-строения в последнее время происходит именно в вебе. Вебари прошли через стадию «херачим DOM JS-лапшой», потом через стадию «херачим DOM jQuery-лапшой», потом бурный период «больше фреймворков богу хаоса фреймворков», из которого наконец выкристаллизовался сначала Angular, потом React, Vue и Elm. И сейчас всё постепенно конвергирует к принципам чистоты и иммутабельности. Как устроен традиционный гуй на Tk/GTK/Qt/Swing/whatever? Это сложное месиво из 100500 объектов, у каждого из них своё внутреннее состояние, и все они связаны адовой паутиной сигналов/калбеков/как они у вас называются. При поступлении евента вызывается обработчик евента, который хаотично меняет состояние какого-то объекта и запускает дальнейшую цепочку событий, которая хаотично меняет состояние дальнейших объектов и запускает дальнейшие цепочки событий. Я вам скажу, даже говнокод на фортране из 80-х приятнее отлаживать, чем цепочки сигналов в недрах Qt. Как работает современный гуй на ненавистном жабоскрипте? Внутреннее состояние UI полностью отделено от внешнего представления. При поступлении евента вызывается функция, которая на основе евента и предыдущего состояния генерирует новое состояние. Затем вызывается функция, которая на основе нового состояния генерирует новый внешний вид UI. (Далее за кадром волшебный фреймворк сравнивает новый внешний вид со старым и применяет изменения к реальному DOM в браузере). Эти функции - чистые без побочных эффектов, отлаживать и тестировать их - просто сказка. Можно логировать всю последовательность состояний и воспроизводить любые баги. Где такое в нативных UI? Пока в Qt и GTK почивали на лаврах и пилили ненужную хуергу, миллионы веб-говнокодеров решали реальные проблемы. А теперь кто-то удивляется, что нативные UI никто писать больше не хочет. Если, блджад, нативные UI на голову лучше веб-говна, ну так сделайте, чтоб они на самом деле были лучше и удобнее в разработке. Не вебарь ни разу, люто ненавижу и JS, и сабж. Просто наболело.

И что сам Qt изначально под мобилки создавался.

А ещё его Нокия придумала. А Нокию основал сам Линус, он же финн.

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

И потом ты поймешь почему веб-макаки таки живут в своем мирке и таки вебмакаки.

Иметь 16Гб только что бы кормить сраный электрон - нет уж спасибо. Но игрушки поиграть - да, нужно.

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

А причем тут среда разработки, это оргвопрос. Если тимлид вменямый. И давай не будем рассказывать себе-любимому как кодить. Сам-любимый пусть как хочет так и пишет. Для себя любимого же. Что ж теперь и дома на кухню строем ходить что-ли.

для єтого нужно просто вызвать функцию с правильными параметрами. Но делфисты упорно смешивают запрос и EditText.

Я таких не видел. Давай за себя говорить. Если ты представляешь группу людей «делфисты» и говоришь что так делать плохо, не делай. Раз ты за эту группу взялся отвечать, вопрос исчерпан.

Уже давно придумали сборщики мусора (точнее ARC) даже для С.

Ага, а самые полезные из них - RCE, мы про них читаем в CVE.

От не надо. Delphi тоже многословен. Но для него нет кучи языков, в отличие от jvm.

Вот только весь тот код, что не логика приложения, - среда генерит, а большинство оберток (циклы, функции, все что захочется) сразу в шаблонах есть, писать только логику приложения и остается.

И в Qt появится чистота и иммутабельность? Или в Qt такого нет, поэтому нинужна?

Та дело не в прожрорливости. Сам электрон - костыли поверх всего с кучей зависимостей, JS + HTML с div элементами повсюду. И FFI враперами вокруг сишных библиотек. Плюс ты с собой постоянно таскаешь браузер. Нет, не движок браузера! А сам браузер(т.е. подключаешь WebKit и десять строк на С++ и ты можешь серфить linux.org.ru).

Потому что вебмакаки не лезли никогда в него и не видели, что по сути это уже VirtualBox с GPU сукорением. Чего только там нет.

«Иммутабельность» это такое модное слово, которым любят вебщики выпендриваться, не понимая что по сути это синтаксический сахар чтобы явно не писать ключевое слово «const», но при этом писать синтаксический сахар как расте «mut».

Динамическое создание форм любых контролов и присвоение к ним евент хэндлеров вручную - сколько хочешь

Только кода больше, чем с каким-нибудь swing или Tk.

Резиновые окна для разных разрешений не проблема

Во-первых, поменяй системный шриф на 150% и твое красивое окно перестает быть красивым. Во-вторых, ты прикладываешь усилия, чтобы добиться нормальной работы на разных расширениях. А менеджер геометрии сам красиво все разместит.

Да и сейчас этот вопрос не до конца решен, судя по тому что я наблюдаю в лине прямо сейчас на hidpi мониторе.

тут от конкретного инструмента зависит.

Иди почитай про persistent data structures.

А ещё его Нокия придумала. А Нокию основал сам Линус, он же финн.

Микка Хаккинен тоже финн, но гонит не так :)

Каким боком понятие «иммутабильность» «persistent data structures» относится к GUI?? Как это должно помогать Qt?

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

Каким боком понятие «иммутабильность» «persistent data structures» относится к GUI??

Таким же, как и к любому другому программированию.