Мне кажется, что для корректного сравнения все же стоило добавить так же часть разработки точно такого же приложения на Electron. И в конце все же их стоит сравнить, а так же сравнить при возможности скорость разработки такого приложения.

Как мне кажется, следует различать ситуацию, когда пишется приложение для АРМ заказчика (автоматизированное рабочее место) и когда у пользователя на десктопе зоопарк electron-приложений.
Если рассматривать первый случай — Вы совершенно правы, и сравнить скорость разработки на разных платформах смысл есть, и выводы могут быть в сделаны в пользу платформы electron.
Но если рассматривать второй случай… У меня, в частности, сейчас запущены skype for linux, slack и atom. И честно говоря, я как обычный пользователь, предпочёл бы иметь их в виде чего-то более шустрого/нативного и с более умеренными аппетитами. И был бы против прироста поголовья постоянно запущенных electron-приложений у себя на десктопе.
p.s. Хотя, справедливости ради, к официальному slack-клиенту претензий намного меньше, чем к альтернативному scudloud и особенно к skype for linux.

У слака это возможно зависит от количества каналов и истории. У меня слак выжирает до 2.5гб. Я писал им в поддержку, они согласились, что это bad experience, но сделать ничего так и не сделали.
Для нас Electron хорошая альтернатива, т.к. у нас есть куча кода, написаного на js/html/css, который используется на сайте. Чтобы не пришлось все это дело переписывать, взяли электрон.
И переложили свои проблемы на юзера. Пусть сам теперь память докупает, чтобы какой-нибудь примитивный чятик на электроне смог сожрать свой гигабайт.
юзеры корпоративные, проблем с памятью нет )
Конечные юзеры вам желают гореть в аду на медленном огне.
В enterprise-аду. И на огне, у которого скорость горения завязана на FPS. :)
ничего они нам не желают, этот софт не для них
Как программист я вас отлично понимаю. Это здорово — иметь одну кодовую базу и писать приложение один раз под все платформы. Я сам так делаю в некоторых наших проектах.
А как пользователь, я эти вечно запинающиеся полувеб-приложения, и тех, кто их пишет, ненавижу. И себя тоже :)

Хотя веб, конечно, тот еще бардак, у него есть два огромных преимущества:


  • веб много лет эволюционировал для разработки UI. В результате в нем есть классные подходы типа FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке (кроме React Native).
  • компонуемость: практически нет ограничений на содержимое элемента, поэтому можно довольно легко делать очень сложные вещи, типа тех же гридов.

Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?


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

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

«Земля тряслась — как наши груди, Смешались в кучу кони, люди, И залпы тысячи орудий.»
В результате в нем есть классные подходы типа FRP

Qt включает в себя язык QML который поддерживает биндинги.
Как я понимаю это то FRP о котором вы говорите.
FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке

FRP на десктопе уже давно.
Например, ReactiveUI появился ещё в 2010 году и, думаю, он был далеко не первым.
> Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?

Вы, конечно же, шутите? Даже в предшественниках — AWT, Swing и если немного в сторону, у SWT, все это было в полный рост, цвело и пахло (как и у любой достаточно продвинутой GUI системы), когда веб пешком под стол еще ходил. Более того, все это делается гораздо проще.

Судя по тому, что я видел на javafx, если говорить о ресурсоемкости приложений, это один из тех случаев, когда ДАЖЕ электрон лучше.

А что вы видели на javafx?

SceneBuilder?

Думаю электрон начал набирать обороты из-за того что увеличились свободные ресурсы в трафике и производительности. (Скачать 10 — 30mb установочник уже не проблема. Мобилки тоже перестали безбожно тормозить).
Ну а популярнее станет тот, в котором быстрее кодить и который прощает больше говнокода)
К Вашему могу добавить еще то, что и яваскрипт машины стали на порядок быстрее
Те микро-оптимизации и приросты производительности совсем не покрывают те запросы на эту производительность, и приложение на электроне, жрущее 1,5гб — обычное дело, и 16 гб рамы теперь уже не выглядит таким уж большим числом, но стоит ли говорить что эти аналогичные этим приложениям на электроне по функционалу и даже особенностям визуального поведения существовали давно и укладывались в килобайты.

Что мы имеем спустя годы? Примерно тоже самое, тоже лагающее, такую же нехватку ресурсов и прочее, просто незаметно для нас, в фоне, выросли скорость и объём, и тут же были нещадно облюбованы поделками, разработанными неквалифицированными офисными рабами негро-индусами разработчиками.

Лично для меня, как для разработчика, а также пользователя, — опыт использования electron-приложений показал что динамические ЯП — моветон, и наивное расточительство, а electron — есть апогей этого порока, убедительная крайность. Electron-приложения я больше не использую, nuff said.

К счастью сейчас есть ряд инструментов позволяющих разрабатывать эффективно, абстрактно и высокоуровнево, при этом сводя к минимуму последствия этих удобств, без всяких виртуальных машин, иногда даже без GC. И как бы между прочим, JVM и этот JavaFX не входят в этот список благодетелей.
И что же это за удобные и высокоуровневые инстурменты, позволяющие писать нормальный не-HTML UI?
Скачать 10 — 30mb установочник уже не проблема

Скорее уж 50+
электрон начал набирать обороты из-за того что...

… в индустрию хлынуло 100500 хипстоты, которая кроме жабаскрипта ничерта не знает и знать не хочет.
Ну, я, типа, хипстота, которая на жабаскрипте пишет. До этого писал на плюсах, на питоне, на похапе. Ответственно заявляю, что на жиэсе лучше всего гуи делать.
Из перечисленного — возможно, особенно питон с похапе показательно. Что касается плюсов, то сильно зависит от фреймворка и среды разработки. Если делать все на WinAPI, то и хтмл раем покажется.
А вы на чем таком пишете, что все основные технологии вам не нравятся? Расскажите, я тоже такой инструмент освоить хочу.
все основные технологии вам не нравятся?

Основные? Для чего они основные? Топик о десктоп-приложениях, каким боком тут PHP с Питоном вообще? Да, я знаю, что и там и там можно писать десктоп, но это не делает данные инструменты основными. Плюсы с QT на порядок приятнее, чем язык гипертекстовой разметки, VCL — на два порядка приятнее, пусть и не кроссплатформа.
Насчет Qt+QML говорить не стану, так как опыта работы с ним даже года нет, с VCL работал около 4ех лет и сказать, что с ним больше не хочу иметь дела, значит ничего не сказать, Сpp+VCL вообще штука не самая приятная, а Delphi как язык меня в результате развития не устроил, FMX был хоть и сырым но более приятным для более сложных GUI. Возможно для сложных программ для работы с СУБД я бы и предпочел VCL/FMX, но не более.
А чем проверенная связка HTML+CSS+JS вам не угодила понять не могу, возможно, только отсутствием визуального редактора.
А чем проверенная связка HTML+CSS+JS вам не угодила понять не могу

А вы точно работали с VCL? А то я каждый раз при разработке веб-чего-нибудь ловлю себя на мысли, что пишу руками кучу кода, который 20 лет назад я набрасывал мышкой за полчаса.
Мне интересно, на каких моментах себя на этой мысли ловили. VCL позволяет быстро набросать форму, но вот в какой-то более менеее сложный UI, а уж, упаси боже, анимации на нем раз в 5 сложнее реализовываются.
но вот в какой-то более менеее сложный UI

Что такое «более-менее сложный UI»? Десктопные приложения «в среднем» всегда имели в разы более сложный UI, чем современные веб-приложения.
а уж, упаси боже, анимации на нем раз в 5 сложнее реализовываются.

Минуточку, мы говорим про библиотеку, которой почти четверть века. В эпоху VCL потребность в анимации UI отсутствовала как класс. Сейчас ну да, хотя возможно за эти годы уже какую-то библиотеку анимации/трансформации наверняка кто-то написал, если этот вопрос вообще был востребован.
Думаю электрон начал набирать обороты из-за того что увеличились свободные ресурсы в трафике и производительности.
я когда вижу, как скайп на моем ноуте под линухом отъедает 3 Гб и 100% процессора, так и хочется увидеть этих программистов и высказать им все, что я о них думаю. Помогает только перезапуск скайпа.
Не хочу омрачать такой пост, но на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.

Он говорит, что изначально проект вообще хотели закрыть, но потом передумали и просто «заморозили его».

Я к тому, что нефиг выпендриваться. Java — это веб-морда, хочешь писать десктоп (натив, глючные электроны или тяжеловесный QT)
тяжеловесный QT

Когда рядом в предложении стоит электрон и Java, Qt становится маленьким и юрким.
я к тому, что писать на нем достаточно проблематично. Ну если, конечно, не использовать обертку в виде PyQT
Если исходить из того, что разработчик уже нанят и знает свой инструмент, то не настолько уж сложно. Тем более, что для фронта есть QML.
PyQt — костыль, потому что Qt — это С++ фреймворк. Писать на нём очень просто, и он совсем не тяжеловесный. Легче может быть только нативный, не кросс-платформенный бинарник (а свой Питон вы в вес приложения не забыли посчитать, нет?).
но на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.

пруф линк?

Думаю, таких статей можно написать по числу языков программирования. Каждый пишет на том, что знает. Никто не будет изучать Java и JavaFX/C# и WPF/Лелика и Болика только чтоб написать одноразовый просмотрщик логов с полутора юзерами, все сделают на том, что знают.

«таблицы стилей безопасных типов»

типобезопасные таблицы стилей

Спасибо!
Вы написали Hello World по сути, а уже потребовалось использовать костыли для поиска стилей на разных ОС. Что же ждет нас дальше?

Я вот добавил в html-ый текстовый input padding-left: 20px и пришлось использовать костыли для работы width: 100%. Что же ждёт нас дальше?

Если вы о расчёте box-sizing, то это не костыль, а документированное поведение

Кто виноват, что такое документированное поведение требует подобных решений?

А выглядит как костыль

а про xul никто и не вспомнил… имхо перспективная штука… была =(
или я что-то перепутал?

Перспективную эту штуку щас добивают в мозилле:)

Что забавно, был момент, когда XUL играл точно ту же роль, что и электрон сейчас. Навскидку припоминаю какой-то перекодировщик видео, который использовал вебморду для интерфейса через XUL, а до или после того — эмбеддед ИЕ, кажется. Был еще то ли плагин для ФФ, то ли отдельное приложение, называлось Prism, это вот как раз как электрон почти было, для построения десктоп софта.

Я не помню, чтобы у кого-то баттхертило (наверное потому что я тогда еще не ходил linux.org.ru) от XUL.
Да софта на нем было было не в пример меньше.

Ну видимо, это и было причиной. :) Тупо некому было.
Проблемы были почти те же (многовато жрет, прилагивает), только пропорционально меньше.
Зато дико перло поначалу, скажем, яндекс-карты обернуть в призму и ярлыком на стол, а в ярлык еще и координаты запихать.
Приложение JavaFX можно скомпилировать в нативное приложение с помощью Gradle плагина:
github.com/FibreFoX/javafx-gradle-plugin
www.youtube.com/watch?v=7n41K2GT9YY
Пробовал компилировать для Windows и Linux — успешно.
Все красивости делаются с помощью CSS

Справедливости ради, это никакое не "нативное" приложение, а только обёртка для вызова утилиты javapackager из JDK, которая упаковывает приложение и JVM в один exe-файл. Хотя для пользователя разница невелика.

Причем, распространять приложение вместе с таким JRE совершенно легально, если вы ничего там не меняете. Пруф с ходу не дам, но вопрос изучал в свое время, была такая необходимость.
JDK 9 в теории может повыбрасывать оттуда все неиспользуемое и футпринт будет уже совсем не в пользу Electron. На практике я это пока не пробовал.
JDK 9 в теории может повыбрасывать оттуда все неиспользуемое и футпринт будет уже совсем не в пользу Electron

Собрал hello world c javafx и выбросил всё лишнее. Получилось приложение + standalone jvm. 44 мегабайта

А в зипе сколько?

zip — 30 mb, 7z — 27

Верно, обертка(не уточнил), но так как конечный пользователь хочет видеть у себя на рабочем столе .exe, а не .jar, то это полезный инструмент и прямо из сборщика проекта.
Самые новые, хипстерские десктопные приложения в наше время сделаны на Electron, в том числе Slack, VS Code, Atom и GitHub Desktop.
Если первые три еще вполне терпимые приложения, то Github Desktop — самое настоящее вселенское (и дико медленное) зло.
имею очень широкий опыт разработки десктопного приложения на javafx 2
  1. стили это очень удобно — можно просто и быстро менять внешний вид, иконки и прочее
  2. fxml — очень крутая штука, как и в qt — qml. Можно отдать на откуп дизайнеру и всё,
    сосредоточиться на коде
  3. куча готовых примеров на все случаи жизни
  4. нет встроенных компонентов для диалогов и визардов, помогает controlsFX
  5. на всех платформах где есть java 8 будет выглядеть одинаково — win32\64 lin32\64, да даже на raspberry pi
  6. глюки в самом нужном компоненте — в таблице
  7. если надо писать gui для desktop java — то лучше не найти, swing — уныл, swt — задобает количеством сборок для всех платформ
А под какие задачи «надо» писать десктоп на Java?
да хотя бы толстые клиенты для серверного софта
Под любые. Хоть текстовый редактор, хоть торрент-качалка, хоть что.

Вообще их неплохо было бы писать на C++(возможно, с использованием Qt), но проще на Java.
Для диалогов можно использовать Alert. Для моих задач его хватало

Ээээ… на всех платформах? Ну, вы же в курсе, что для ARM fx нет и не будет?

Для распбиана в репах openjfx всё ещё доступен. Но проблема в консерватории есть, да.

А он нужен для разработки или для запуска получившегося jar тоже?
Если я ничего не путаю, там тупо запакованы javax, нужные для запуска.
JavaFX is not part of the ARM JRE
Угу. Без веба. Очень старой версии (был, сейчас е знаю). И не запускался, т.к. нужно было либу дособирать.
почему же нет?
скриншот
image
Потому что нормальной свежей версии без костылей и с вебом нет.
веб работает, вот скриншот моего майл клиента на java fx, компонент WebView
а о каких костылях идёт речь?
скрин с вебом
image
Позвольте внести свои 5 копеек.

Имею Java FX 8 приложение в продакшене.
Кроссплатформенность была обязательным требованием…
Выбирал между Electron, JFX, Qt, Lazarus.

Qt отпал из-за цены.

Еще сильно жали сроки, поэтому пришлось писать на максимально знакомом языке/платформе.

Наблюдения:
— У лазаруса размер исп. файла самый приятный (боюсь соврать, но мин. приложение с голым окном — 1мб).
— С лазарусом я не подружился еще на этапе установки. А уж писать прод на такой незнакомой платформе был бы самоубийством. Допускаю возможность, что в опытных руках — вполне годно.
— Очень частый вопрос — почему не Swing — «то же самое же». JavaFX лучше Swing хотя бы уже нативными диалоговыми окнами (Open File итп). Не говоря о поддержке.
— А вот систрей все тот же AWT-шный. Обещали вроде к Java 9-10, но воз и ныне там
— он же на linux работает кое-как (проблемы с меню, с размерами иконок).
— GUI довольно неспешный, особенно загрузка
— Java FX просто ужасен с точки зрения юнит-тестирования. Нет интерфейсов, классы насмерть прикручены к самой платформе и работают только с ней и в ней
— В целом все ОК. Дефалтный look-and-feel выглядит средне, позывов рвоты как Swing Metal не вызывает.
А, если не секрет, из-за какой цены отпал Qt?
Почему же секрет — вот www1.qt.io/buy-product

А это причина, по которой OSS лицензия не подходила.
A commercial license keeps your code proprietary
Ну тогда если не секрет, почему опенсорсную лицензию не рассматривали.

Available under GPL & LGPLv3 licenses
info.qt.io/download-qt-for-application-development
Верно, LGPL вроде бы подходил, но там были нюансы с линковкой. Думаю, что я бы на этом на какое то время увяз, не имея опыта с Qt (и вообще в целом опыт с С++ только в далекие студенческие времена. Да и то скорее — опыты, а не опыт)). А времени было 2 недели на апп + бэкенд.
Да, вы правы, это был очень слабый аргумент. Или неверный.

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

Если совсем коротко — линкуетесь с Qt динамически (фреймворк в отдельных DLL/SO) и творите что хотите. В своём коде конечно.

P.S. в то же время так противопоставлять Electron vs Java FX — это ИМХО несколько перебор.
Делаю хобби-проект с BLE 4.0. Тоже нужна небольшая программка, сидящяя в трее. С BLE 4.0 в Java довольно печально. Qt традиционно «не осилил», хотя честно пытался) А вот для node.js библиотека завелась с полтычка: github.com/sandeepmistry/noble. Если учесть, что мне еще нужны веб-сокеты для интеграции с внешним сервисом, а каких-то ограничений по размеру/производительности не стоит — выбор Electron выглядит вполне разумно.
С BLE 4.0 в Java довольно печально.

А смотрели на таких ребят как Bluegiga? Есть у них такая библиотечка для BLE.
Спасибо за линк, нет, не видел.
Смущает следующее: «All you need is a BLED112 dongle on a PC.». Это реализация API для конкретного адаптера?
Да, для группы адаптеров Bluegiga. Из тех решений на java, что я видел, это мне понравилось больше всех. Если кто то подскажет более идеальное и без привязки к адаптеру, буду премного благодарен.
Боже упаси от десктоп приложения на Java!
А что не так с java?
Java — серверный язык. Он хорошо работает на определенных машинах, с определенным софтом (основным и вспомогательным), с хорошим прогревом и прочее.

Когда пытаешься все это перенести на машину обычного пользователя, получается какой-то ад, и практически 100% что-то будет отваливаться, тупить и приносить «радость», не говоря уже про обновления.
Что за чушь?
Я пишу под десктоп на Java. И почему-то мои программы до ПОЛНОСТЬЮ рабочего состояния (т.е. никакой «активации модулей» при первом открытии меню, вся графика уже в кэше, пул соединений с БД инициализирован) запускаются за 5-10 секунд. И почему-то они работают и под виндой, хотя разрабатываю полностью на лине. И ничего не «тупит» и не «отваливается».

Возможно, я что-то делаю не так? Поделитесь пожалуйста опытом написания тормозного и глючного софта, будет очень интересно послушать.
Запуск за 10 секунд это и есть тормозной софт. Не тормозной софт запускается за долю секунды.
Софт бывает разный. Для мощной IDE, например от JetBrains, 5-10 секунд это нормально.

7-10 секунд для веб сервера с фреймворком типа Spring и ORM — тоже не много.

У меня Netbeans стартует секунд 40 и потом проекты открывает минуты две, хех. На Q9550 особо не побегаешь.

А у вас система(или JDK), IDE и проект лежит на SSD?
Если нет, то узким местом является HDD, а не процессор.
Да, на SSD. Перенос ускорил сабж процентов на 25.
Собственно, на домашнем компьютере IDE за 15 секунд запускается, софтина — за 7, из которых 4 — кэширование графики и 1.5 — самотестирование и подобный трэш.

А что у вас с оперативкой? И какая ОС (точнее важнее вопрос — отключён ли своп к ...)?

С оперативой всё плохо, она работает на 800 МГц.
Ось — бубунта. 16 с копейками.
Своп не отключен, я часто выхожу за имеющиеся 16 Гб. Я вообще считаю отключение свопа чем-то вроде спиливания прижин на автомобилях. Не надо его отключать.
Своп не отключен, я часто выхожу за имеющиеся 16 Гб.
Гроб. С музыкой. Докупить памяти и не мучаться.

К огромному сожалению Linux очень плохо работает со свопом. Потому что просто исторически считалось, что раз система ушла в своп — то всё уже и так очень плохо и можно «расслабиться». Появление SSD заставило людей задуматься об этом проблеме, но когда своп в Linux будет работать хотя бы сравнимо с тем, что в *BSD — науке неведомо.

Хм… Нет, даже в винде, где своп вылизали как могли >10% оперативки в свопе замедляют работу. >50% делают её паталогически неспешной с подвисанием UI.
В линуксе своп не нужен от слова совсем, но менеджить доступный объём приходится руками — это да, непривычно. Впрочем я и на винде при наличии возможности отключаю своп.

Отключение свопа — это уж совсем странное действие. Типа как срезать ремень безопасности, чтобы почуствовать себя «настоящим пацаном».

Дело в том, что ни в Windows, ни в Linux вы не сможете отключить своп «по настоящему». Потому что странички, принадлежащие программе всегда могут «уйти в своп» (их можно выкинуть из памяти, так как всегда есть возможность загрузить их из оригинального файла). То есть если у вас начинает кончаться память при наличии свопа — система замедляется, если то же самое происходит при его отсутствии — она замедляется катастрофически.

В Android'е эту проблему решили «ручным» OOM-киллером: процессы убиваются до того, как система «встанет колом». Но на десктопе соотвествующего watchdog'а нет, потому своп должен быть…
en.wikipedia.org/wiki/Swappiness
>Swap is disabled. In earlier versions, this meant that the kernel would swap only to avoid an out of memory condition, when free memory will be below vm.min_free_kbytes limit, but in later versions this is achieved by setting to 1. See the «VM Sysctl documentation».

Не знаю с какого ядра это поменялось, но при =0 не наблюдал свопа даже напрямую из исполняемых файлов. А так вы правы, и винда и линь (при =1) могут вытеснить страницы, занимаемые кодом, даже при отсутствии своп файла\раздела.
Нет, даже в винде, где своп вылизали как могли >10% оперативки в свопе замедляют работу.

Интересно, каким магическим образом память неактивных программ может вызвать хоть какие-то тормоза? Пусть даже там будет 10% памяти, если она не принадлежит активным процессам, вы заметите только ускорение за счёт большей свободной памяти для кеша и активных программ.

Процессом чтения-с-диска/записи-на-диск вестимо. Или у вас только ssd уже?

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

Запись-на-диск — сброс свопируемых страниц. Чтение-с-диска — загрузка данных с диска (генерация данных прям в памяти — явление всё же редкое) и/или восстановление свопнутых страниц.


Если всё это происходит на классическом диске — это не очень быстро.


Если у меня приложениям (в сумме, вместе с системой) надо 10-12Гб оперативки, а у меня её только 8 — начинаются пляски. Расклад:
Ide ~2Гб
Браузеры (chrome + FF) — по 1Гб (минимум)
система + прочие приложения (по ощущениям — не меньше 1Гб, но больше похоже на 2)
и компиляция проекта GWT — 3-5Гб.


Если перед компиляцией выгрузить что-то одно ресурсоёмкое — система лишь немного подтормаживает после компиляции (и полностью тормоза лечатся — только перезагрузкой компа).


Если запускать прям-так, то компиляция происходит в ~2 раза дольше (9-15 минут) и после компиляции весь UI стоит колом (каждое переключение между вкладками браузера, каждое переключение между окнами приложений — тормоза. В течении получаса само не проходит, дольше не вытерпел — перезагрузил систему).


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

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

PHP — это серверный язык, а Java — это язык общего назначения.

Сижу и кодю на "серверном" языке под Android...

Её успешно демонизировали пользователи глючных банк-клиентов. А Оракл не сделал ничего, чтобы исправить ситуацию.
А также ИМХО отсутствие вменяемых ограничений хипа по умолчанию.
Пользователи смотрят кол-во занятой памяти — «ооо, Джава жрет».

Ну много ест памяти, требует зачастую JRE если не собрано с ним, тормозит и очень долго стартует если комп не самый быстрый и без SSD, ну и самое важное для меня чудовищно ест батарею на ноутбуке. Ушёл кстати от продукта JetBrains PyCharm на VS Code и не жалею.

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

Продуктами от JetBrains не пользуетесь?
Вот именно поэтому )
Один хипстер обвиняет других что они хипстеры, нет нечего лучше чем Smalltalk and Lisp family, а ваши детские языки с сахаром от которого диабет уже превысил все возможные нормы для жизни только усложняют жизнь, а не облегчают!
Пункт подрыва завершен, а теперь конкретнее:
  1. У Kotlin ужасная реализация параллельного программирования, т.е. я бы назвал ее вообще нет,
    реализация паралелки через итераторы я считаю наркоманией
  2. Сказать что сопрограммы/корутины наркоманские, не сказать нечего, вы видели его синтаксис? Блин,
    по сравнению с ним С++ реализация кажется очень красивым и лаконичным
  3. Чем вам .core C# не понравился кроме религиозной причины? Обилия сахара максимум, тут и async/await с пол пинка, тут и Thread/Task заводится без усилии, лаконичные делегаты и общирные возможности полиморфизма встроенных объектов ну и кроссплатформленный, покрайне мере проверял и запускается на каждом древнем тапке с Debian 6-7 на борту
  4. Что бы вы ни думали о JVM, не существует никакой другой платформы (кроме, может быть, самого Electron!), настолько простой для кросс-платформенной разработки. Как только вы создали свой jar, на любой платформе, вы можете распространять его среди пользователей всех ОС — и он просто будет работать.
    чушь, как минимум C# .core еще кидаем в копилку TCL and Smalltalk and Lisp Family and Haskell and Fortran and Rust and Golang and… Java не универсальный нож, а в истории выехала только за счет рекламы Sun

Итог, Kotlin отлично подойдет сделать что-то быстро и не заморачиваясь над деталями, синхронные приложения писать на нем можно как нечего делать, а вот как только понадобится решить задачи связанные с многопоточным выполнением, там отхлебнете, да и плюс машина JVM очень прожорливая, так что если потребление ресурсов не является ключевым, то эта «технология» подойдет. Но выражения автора статьи меня подвергли к написанию такого вот объемного текста, не люблю когда кто-то преподносить технологию как панацею, это не профессионально просто.
> да и плюс машина JVM очень прожорливая

Слишком широкое заявление. По сравнению с чем? На каких задачах? При каких настройках/ограничениях? У меня rails worker'ы больше памяти потребляют, чем куда-более нагруженный java сервис. Но выводов каких-то я из этого не делаю. Задачи разные и решены по разному.
> Чем вам .core C# не понравился кроме религиозной причины?
Тем, что под него нет десктопного UI? AvaloniaUI пока в ясельном возрасте.
А как же Xamarin.Forms/WPF + XAML?
iOS, Android, Windows, Mac OS, Linux, даже никому не нужные Windows Phone и Tizen.
Я не удивлюсь если в течении полугода они принесут Forms в браузеры через WebAssembly (a.k.a реинкарнация SilverLight)

Стоп, но что из перечисленного относится к теме кросплатформенных десктопных приложений? (статья про них)

Xamarin.Forms + Mac OS/Linux и в какой-то степени WPF + Windows. Конечно комбинация Forms + WPF не может считаться полностью кроссплатформенной для десктопов, но определенно есть множество общих знаменателей.
А можно ссылку на гуевое приложение на Xamarin.Forms работающее на Windows, MacOS и Linux?
Желательно (но не обязательно) с открытыми исходниками (чисто любопытство).
Например это для Windows и Linux
Я не эксперт, но мне кажется что прикрутить Mac OS как минимум возможно.
Спасибо, изучу на досуге.
У Kotlin ужасная реализация параллельного программирования, т.е. я бы назвал ее вообще нет, реализация паралелки через итераторы я считаю наркоманией

Вы смотрели https://kotlinlang.org/docs/reference/coroutines.html?
Что такое "реализация паралелки через итераторы"?

Веб, при всей своей ужасности породил очень удобные инструменты отладки вёрстки, и множество других инструментов. Такой удобный дебаггер как хром дев тулз ещё поискать нужно в других экосистемах. Я не только про отладку именно кода, хотя и там асинк коллстеки это нереально круто, но и инспектор dom и удобство его модификации, и профайлер с таймлайном и куча других вещей на расстоянии клика. И интерфейсов в вебе верстается сейчас не в пример больше, и опыт там копится быстрее.
Конкурентом Electron можно считать Sciter — HTML + CSS + JS-like script. Написан на С++, не требует JVM и прочих зависимостей. Отлично интегрируется с бизнес-логикой на С++.
Да, вот было бы интересно увидеть приложение аналогичное Sciter Notes на JavaFX:
image
У меня это заняло два месяца этим летом.

На JavaFX можно и JS использовать.
Главная причина, почему Electron настолько популярен: не нужно переписывать уже написанное. Имея уже веб приложение, вам не потребуется много сил для натягивания его на Electron. Если же делать десктопное приложение с 0, то вам не придется искать новых специалистов. Берем имеющихся веб-разработчиков и усаживаем их за Electron и кошелек доволен и скорость разработки высокая. Например, тот же Slack так и поступил. Про легкость создания и настройки UI говорить не стоит.
Главным же недостатком Electrone является его прожорливость и большой вес даже минимального приложения. Я вижу такой путь к решению проблемы: завозим Electron в качестве VM, а exe-шник приложения по сути его запускает и скармливает нужные данные. И получаем сразу -90% от общего веса приложения (даже если от проблем с ОЗУ это спасет не особо, то компактность увеличит значительно), а о проблеме с ОЗУ надо уже отдельно думать.
Потом к этой виртуальной машине нужно приделать инпут-онмнибокс, в котором можно указать URL «программы» и… получим браузер.

Хм… Так это… Та же Idea умеет какие-то функции выбрасывать в локальный браузер… в чём тогда проблема вместо запуска толстого клиента вообще поднять локальный сервер, который будет работать с браузером?.. вряд ли это будет дороже, чем Electron...

Не стоит забывать, что Eдectron не только Chromium, но и Node со всеми отсюда вытекающими: работа с файлами, взаимодействие с ОС. Поэтому слова, что мы получаем тот же браузер не совсем верны. А вот насчет надбраузера, так на нем его уже сделали: Brave(правда там форк Electron-а и цели несколько иные нежели чем у обычных браузеров).
Если уж кому-то совсем в край извратиться тот же сервер можно для управления обернуть Electron-ом(но это надо уж совсем извращенцем быть)

А такие решения уже есть. есть такая штука как cuba platform, так у них IDE это веб приложение поднимаемое на localhost'е.

Вообще странная идея — имея сайт волочь его на десктоп.

Про легкость создания и настройки UI говорить не стоит.

Легкость для кого? Весь ужас и ад инструментов современного веба приходит на десктопы?
Ну этот ужас и ад будет ограничен единственным движком от Хрома (а не зоопарк Chrome-FF-Edge-Opera и тд), да ещё и версия движка на ваше усмотрение.
Нет же) У нас есть уже сайт со всеми этими потрясающими костылями. Иначе зачем нам вообще Electron?
Сколько я ни пытался изучить Java, так и не смог его понять. Это просто какой-то вывих мозга. Наверное при обучении надо сначала свернуть себе мозг, чтобы он перевернулся в черепе. А потом уже можно спокойно писать.

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

А вы часом не справочник по Java читали?
Если вы только начинаете разбираться в программировании — то может стоит взять Head First Java?

Как страшно учиться чему-то новому, ведь придётся же учиться чему-то новому.

Покажите пример, как лучше.

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


Встраиваемый IE активно используется в Десктоп-приложениях года эдак с 2000. Есть и такие, в которых используется «встроенный IE + встроенный веб-сервер + встроенный PHP».
Я — мобильный разработчик, в основном Android. Пробовал JavaFX — это ад какой-то с точки зрения верстки. Вроде и там и там всё в XML похожим образом делается, но в JavaFX это делается как-то через задницу. Не могли что ли у андроида подсмотреть?
Оно раньше Андроида появилось. Но тут есть важная разница: JavaFX создали архитектрные астронавты, которые сами на нём ничего особо не писали. А Андроиду — нужно было, прежде всего, заставить работать те приложения, что с системой поставляются. А уж потом — всё остальное.

Все хорошо, но…
В fx нет нормального контрола для вывода rich text. Так, чтобы пользователь выделять мог, чтобы можно было динамически изменять, чтобы картинки были, чтобы нажатия определять. Или встроенный web со всем сопутствующим адом. Или чего-то не будет. И это катастрофа. Особенная катастрофа, если вначале казалось, что это приложению не нужно, а потом понадобилось.
Это очень серьёзный недостаток и причина, почему я с болью буду слезать с fx, имея уже готовое приложение.
Вторая проблема — fx нет и не будет на ARM. И это тоже катастрофа. Этот рынок сейчас растёт и потребность уже есть. Это потеря кросс-платформенности и вторая причина, почему мне придется отказаться от fx в пользу swt несмотря на потерю кучи времени.
И конечно же баги и архитектурные просчеты, которые висят десятилетиями. Попробуйте динамически менять псевдоклассы контролу. А без этого даже нормальной лейбы меняющей цвет фона нормальной не сделать. Есть ещё беда с таймерами и вызовом функций fx. Есть горе с динамическим определением и изменением размера окно (окно, которое имеет заданный размер клиентской области, например — простейшая вещь). Огромная проблема со сглаживанием шрифтов (попробуйте запустить приложение на Linux-системе с двумя мониторами) Это из простого, известного и первого пришедшего на ум. Казалось бы без этого можно жить, но в результате затраты на написание качественного GUI-приложения оказываются огромными, а некоторые простейшие, но заметные пользователю вещи просто невозможны.
В результате совершенно невозможно это использовать для серьезных долгоживущих проектов — только простейшие поделки. В то же время тот же swt позволяет все эти проблемы решить. Некоторые с болью и слезами, да. Но со временем это компенсируется наработками и окупается качеством пользовательского интерфейса и скоростью разработки последующих проектов.
Короче, после долгого времени активной разработки на fx (и даже массы восторгов на первых парах) пришло ужасное понимание, что несмотря на все наработки, в перспективе это тупик — риски велики, затраты тоже велики, результат проигрывает конкурентам.

Ох, парни…
Информация из двух комментариев, Terras и вашего, меня повергает в уныние…

— «на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.»
и
— «fx нет и не будет на ARM»

Недавно перенёс десктопное приложение (таблицы, формочки, картография битмап+векторная, графики) с Java7+Swing на Java8+JavaFX, в связи с тем, что пришлось добавить поддержку воспроизведения видео и в перспективе маячили 3D-схемы пром.объектов.
Чуть было не завёл на iMX6+FrameBuffer на одной промплате, споткнулся/завис на шрифтах, пока отложил, нет опыта в сборке правильного линюкса под это дело.

Самое время переходить на Java9+SWT? Грусть. И х86 на девятку вроде как решили не завозить…

Других вариантов нет?

P.S. Qt не вариант по ценам и по тому, что есть порядочно общей кодовой базы между сервером/десктопом/андроидом.
P.P.S. JavaScript. Писал немного в молодости, с тех пор готов влезть в Kotlin/JS, лишь бы не в яваскрипт.

JS из молодости и современный ES6+, к счастью, довольно разные вещи.

МОжно попробовать PyQt, но там вопросы быстродействия на ARM вылазят.
SWT тоже не сразу там заводится, но там хотя бы принципиальный препятствий нет и есть хоть какие-то работающие готовые решения.
JS на embedded ARM?! При одном гиге ОЗУ, например? Очень странное решение. Это возможно. И даже работать будет, но нужно будет решать массу проблем по работе с ситемными ресурсами.
Пока, да, для ARM хорошо работает только C++/Qt и JS с некоторыми оговорками. Есть случае стабильной работы Java+SWT, но уже сложнее. Всё остальное не портабильно, в общем случае.

Вот тоже расстраивают скудные возможности работы с просто текстом. Там есть что-то, но закинуто в пакеты com.sun.javafx.*, что означает, что в Java 9 придётся прописывать дополнительные разрешения для модулей, да и документации почти никакой.


И рендеринг шрифтов слабоват даже под Windows — раздражающая муть, так как субпиксельное сглаживание работает не пойми как. Но такая муть сейчас стала везде — и в Chrome, и в новом Firefox. Но это из-за того что GDI не используется, а D3D и прочее "аппаратное ускорение". Что удивляет, что народ эти мутные шрифты повсеместно терпит и даже вроде как не замечает.


Зато вот сборка OpenJDK от JetBrains под Windows использует нативный рендер и сглаживание, что вкупе с программой MacType даёт тексту отличное качество.


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

Нашёл библиотеку RichTextFX, но с JDK 9 она уже не работает, надо переписывать. И то постоянно предупреждения из-за того, что залезает во внутренние непубличные пакеты.
Я писал несколько внутренних проектов на JavaFX, и в следующий раз буду писать на Electron, и вот почему:
— кроссплаформенность Electron выше. Например, у меня на Linux в WebView плавают цвета шрифтов.
— Electron позвляет использовать JS фреймфорки, а тот же Vue намного удобнее API JavaFX. В дополнение можно взять какой-нибудь ElementUI со стандартными компонентами.
— CSS в JavaFX — это такой очень специфичный CSS, писать и отлаживать который сущее мучение. Постоянно приходится луркать по стандартному modena.css и смотреть какие и где используются селекторы.
— платформа стагнирует, комьюнити не развивается и это очень заметно.

JavaFX в сравнении с Electron выигрывает только «бэкендом». Java позволяет использовать любые библиотеки, а вот с бинарными зависимостями в nodeJS придется попариться.
Как по мне Java во многом уступает JS языку изза большей развитости последнего. А сравнивать ооп язык и мультипарадигмальный язык вообще не стоит — последний будет всегда лучше для разработки.
Как по мне Java во многом уступает JS языку

А во многом это в чём? Хотя бы 3-4 пункта. У JS вообще есть один существенный минус по сравнению с Java. Можно писать на каком-нибудь другом языке и компилировать его в jvm байт код. А вот в случае с джаваскриптом, если пишешь на другом языке — его можно скомпилировать только в джаваскрипт, со всеми вытекающими.

Как по мне Java во многом уступает JS языку изза большей развитости последнего.

Примеры в студию.

> Пишем быстрое десктопное приложение на JavaFX

Это шутка такая? На жабе для десктопа разве только развесистые профессиональные приложения писать не требующие высокой производительности. А так все гуи-приложения что видел на любом жабовском фреймворке для десктопа ощутимо неспешны.

Не, конечно аполегеты утверждают иное, но в реальности я ещё ни разу не видел нормально работающее десктопнее жабо-приложение: медленно запускается, ощутимо медленно открываются окошки, ощутимо медленно происходит реакция на всякие нажатия и т.п.
Если не видели, то подскажу: Idea, Android Studio.
Идея не то, чтобы быстрая, но сносная.
Запустил я как-то её на стареньком ноуте с 2 гигами памяти на HDD… Ага, конечно, сносная — если у вас ресурсов немеряно.

Как тут уже многие говорили: монстр Qt (реально монстр и тормоз если сравнить его с фреймворками XX века!) становится маленьким и юрким, когда его начинают сравнивать с Electron'ом и JavaFX…
Запустил я как-то её на стареньком ноуте с 2 гигами памяти на HDD… Ага, конечно, сносная — если у вас ресурсов немеряно.

А на какой девелоперской машине их сейчас мало?

Не путайте тёплое с мягким, пожалуйста. Вопрос был: «бывают ли быстрые декстопные жабо-приложения». Ответ — нет, не быват, и Idea/Android Studio контрпримером не являются, оно тормозит безжалостно и не кажется ужасным кошмаром только за счёт того, что деволоперы работают на машинках за $5000, а не за $500.

Если же ваше приложение рассчитано на более широкую аудиторию, то этот подход — не очень годится: если это ваше основное приложение, которым вы деньги зарабатываете, то вы можете ему это простить и прикупить для него «лишние» 4-8-16GB памяти, но если это какой-нибудь проигрыватель музыки — то вы, скорее всего, предпочтёте что-нибудь другое…
На старом ноуте с HDD тормозит все. В особенности «програмные монстры» типа браузеров и IDE.

Мне приходилось работать в Eclipse на старом ноуте с целероном, 2 гигами оперы и SSD. Было вполне конфортно и без ужасов, которые вы описываете.

Обычные приложения на java (не монстры) даже на слабом железе работают быстро.
На старом ноуте с HDD тормозит все.
Позвольте мне не поверить. Visual Studio 6 или какой-нибудь Delphi 2.0 там «летают».

В особенности «програмные монстры» типа браузеров и IDE.
В случае с браузерами всё в меньшей степени зависит от браузеров и в большей — от сайтов, которые вы посещаете. Какой-нибудь gcc.gnu.org или там lwn.net тоже нифига не тормозят несмотря на «жалкие» 1GB памяти и «несчастный» Atom, а вот банк-клиент на каком-нибудь «моднючем» фреймворке — тут да, без слёз не взглянешь.

Обычные приложения на java (не монстры) даже на слабом железе работают быстро.
Не заметил. Опять-таки: uTorrent на этом самом Атоме летает и систему не грузит, как Vuze запустишь — так она только им и занята. Даже если там не так много активности.

У Java-приложений много достоинств, но скорость работы и потребление ресурсов у них ужасны. То, что Electron побил все рекорды и теперь простенький редактор занимает не пару мегабайт в памяти, а пару гигабайт не означает, что Java вдруг стала менее жрущим монстром.
Позвольте мне не поверить. Visual Studio 6 или какой-нибудь Delphi 2.0 там «летают».

VS6 на 166MHz и 32MB оперы неплохо работет.
Говоря «все» я не имел ввиду калькулятор, notepad и ПО из прошлого века…
На атомах и целеронах с HDD даже проводник лагает…

Какой-нибудь gcc.gnu.org или там lwn.net тоже нифига не тормозят несмотря на «жалкие» 1GB памяти

А запуск? Firefox на атоме не сильно спешит открываться. Интерфейс тоже имеет заметные лаги.

uTorrent на этом самом Атоме летает и систему не грузит, как Vuze запустишь

А вы уверены что причина в java, а не в кривых руках или в нежелании оптимизировать код для слабых ПК?
К тому же они не идентичны. У Vuze больше наворотов, что могло сказаться на производительности.

У java очень навороченный JIT. Производительность кода на java не сильно хуже кода на C++.
Из за виртуальной машины запуск java приложения более тяжелый чем запуск ПО на C++ и оперативку она с запасом берет (JavaFX 75MB).
В этом плане java хуже чем C++, но это плата за кроссплатформенность и прочие штуки, за которые ценят java.

В любом случае java не хуже чем C#(.net), который не называет на каждом углу тормозным…
А запуск? Firefox на атоме не сильно спешит открываться.
Там Windows XP и, соответственно, Chrome 50, но он достаточно быстро запускается. Гораздо быстрее, чем Firefox или «родной» MS IE.

К тому же они не идентичны. У Vuze больше наворотов, что могло сказаться на производительности.
Больше наворотов в UI? Какие же?

В любом случае java не хуже чем C#(.net), который не называет на каждом углу тормозным…
Почему не называют? Называют. Только на Android'е. В обоих случаях за счёт интеграции с системой им удаётся несколько смягчить проблему. И в любых случаях когда этой поддержкой не удаётся воспользоваться (когды вы какой-нибудь «adb input tap» запускаете) — всё тормозит.

В этом плане java хуже чем C++, но это плата за кроссплатформенность и прочие штуки, за которые ценят java.
А с этим — никто и не спорит. Я вполне готов использовать какой-нибудь CLion — но не в силу его отзывчивости (которой там, в общем-то, не особо пахнет, как и в любой программе на Java), а в силу того, что он просто умеет больше, чем MSVC 6.

Говоря «все» я не имел ввиду калькулятор, notepad и ПО из прошлого века…
А почему, собственно? Почему что-нибудь подобное сделать «с технологиями прошлого века» — не проблема (и оно будет работать на 32MB и «летать» на 64MB/128MB), а современными — оно будет жрать пару гигов?

Что и где «пошло не так»?
Больше наворотов в UI? Какие же?

У Vuze нестандартный интерфейс с мелкой анимацией и штуками типа Swarm view. Плюс p2p чат, плагины итп. Все это сказывается на потреблении CPU и оперативки.

Плюс невысокое качество кода (он жрет 2-3% ядра i7 2600MHz даже когда не качает) и мы получили тормоза на атоме.

Почему что-нибудь подобное сделать «с технологиями прошлого века»

Разработка нестандартного(не нативного) интерфейса (ака WinAmp) требует квалификации и времени.
На электроне намного легче и быстрее сделать такое приложение (Тяп-ляп и в продакшн). А дикое потребление оперативки и лаги — проблема пользователей, пускай купят новый ПК…

Если говорить про IDE:
Сейчас текстовые редакторы, типа Emacs, могут больше чем IDE прошлых веков.
Дополнительный функционал + экономиия человеко-часов разработчиков — это причина появления монстров, которые требуют дорогое железо.

С операцонными системами точно такая же ситуация.
А можно поинтересоваться, это точно хром 50? Не 49.0.2623.112?
Драсьте!
Я каждый день использую Gogland, чуть реже CLion.

Софт от Jet Brains это типичный образчик «развесистого профессионального приложения». Gogland, в принципе, работает сносно, т.к. Go сам довольно простенький. А вот CLion иногда еле-еле ворочается на не самых больших кусках.
Хорошая статья.
Долой хайп, пишем на брейнфаке.
Просто потому что мне нравится брейнфак, а не потому что хайп не зря.
есть ли приложение на JavaFX, которым можно гордиться?
Да, у нас NASA есть какая-то херня, которой можно траекторию спутников высчитывать и что-то еще делать. Они его написали на JavaFX, так как биг-дата толи на скале, толи на Java считались.

А так нет =)
мне кажется хороший пример использования его :)
bitbucket.org/JavaSabr/jme3-spaceshift-editor
Есть неплохая библиотека реализующая MVVM:
Ссылка потерялась куда-то.
mvvmFX на GitHub

У меня Intellij IDEA запускается за 10 сек, а Visual Studio за 1 мин 20-30 сек (сами проекты не открываются). NetBeans за 30 сек. То время, когда написанное на Java быстрее, чем на c++

У меня Intellij IDEA запускается за 10 сек, а Visual Studio за 1 мин 20-30 сек (сами проекты не открываются).
Серьёзно? Это Visual Studio 6.0 у вас на машинке, где IDEA за 10 секунд запускается больше минуты стартует???

То время, когда написанное на Java быстрее, чем на c++
Последняя версия Visual Studio, написанная на C++, это, я таки извиняюсь, Visual Studfio 6.0. После этого там завёлся C# — и чем дальше, тем больше (в первых версиях Visual Studio .NET на нём пара Wizard'ов, в Visual Studio 2017 — почти весь интерфейс). Результат немного предсказуем.

То, что Intellij IDEA написана весьма и весьма качественно — общеизвестно. Но, пожалуйста, не нужно её сравнивать с нативными C++-программами.

VS 2015, windows 7, RAM 4GB, HDD. Проект с шаблоном asp.net mvc в нем слишком долго создается вплоть до минуты, даже в NetBeans до 15 сек занимает создание проекта с шаблоном web.

Ну дык эта: архитектурная астронавтика и C#, чего вы хотите? Как я уже сказал: Visual Studio на C++ — это история. Это из LibreOffice выпиливают Java'у (и последние версии пошустрее работают), в Visual Studio — наоборот…
Серьезно, выпиливают? А на что заменят и есть ли навскидку ссылка почитать про эти планы?
Вот прямо у них на страничке Development/Java. Она, собственно, с этого тезиса начинается. А закачивается разделом «Suggestion to Remove Java Components».

На что меняют? На то, что и было: C/C++. Но Sun успел изрядно засрать кодовую базу компонентами на Java, работы много.

Статья была создана в 2012 году, все проверки проводились с кодом версии 4.2.6.3(28-Aug-2014 03:09) Скачал последние исходники и сделал первую проверку — отсутствует только одна директория accessibility/ так что про полное выпиливание пока речи не идет

Кстати, поздно вспомнилось, но раз тема про электрон, то грех было бы не упомянуть: есть такая фришная игра Duelist, карточно-тайловые бои, пиксельная (на мой вкус — слегка чересчур) анимация фигур и очень красивые арты, но речь не про качество игры как таковой.
В версиях до релиза (сейчас не проверял), игра скачивалась в двух частях — сначала лаунчер, а потом в нем авторизация и докачка основного тела игры, ну в общем все как обычно.
Суть прикола — лаунчер сделан на электроне, но закачивает он игру, которая тоже на электроне, даже файлы те же самые! Но при этом игра занимает МЕНЬШЕ лаунчера, КАРЛ! %) Примерная пропорция — где-то 150 метров на лаунчер и 120 на игру. :D
Единственное объяснение (если оно кого-то заинтересует) — в лаунчере замастрячили интро-видос в фуллхд и много анимированного графона на задник и кнопки.
Небольшое замечание по фактам из статьи. Абзац, начинающий словами
Oracle чуть не испортила всё с самого начала, приступив к созданию особого, декларативного языка, который предполагалось использования для создания UI приложений...
следовало бы написать чуть-чуть иначе. А именно: «Sun чуть не испортила всё с самого начала...»
Это солнечные зачем-то ввели скриптовой язык для JavaFX. На мой взгляд — неразумное решение. Oracle же, после покупки Sun, всё это стряхнул и начал чуть ли не с нуля, сделав замечательный инструмент — новый JavaFX-2. Ну и далее 8 и 9.

Мне не пришлось пока писать софт на JavaFX для продакшена, но для своих проб я его использовал. И мне он исключительно нравится. Реальным конкурентом вижу только Qt но… С++ таки сложный язык. И он постоянно меняется в сторону усложнения. В своё время я писал на нём лет 10, то есть, я в нём не новичок, хотя и подзабыл уже. Опять же много нового появилось. Но даже после этого, попробовав Qt, просто руки опускаются когда приходится слазить с Java, и особенно с IntelliJ IDEA. На Java под IntelliJ код словно сам стекает из мозга на экран.

А что касается Javascriptа. Это адский ад, а не язык для промышленной разработки. Тот человек, который его придумал, вряд-ли предполагал, что на нём будут писать куски кода длиннее 20-30 строк. Но чудеса движения цивилизации неисповедимы. К счастью, Микрософт тут внёс полезное в индустрию. А именно — придумал и реализовал TypeScript. А это уже заметный шаг в сторону сил света.

Последний мой проект идёт на Angular 4, но это не десктоп. И я по прежнему внимательно слежу за JavaFx. Читаю блог одного из разработчиков с новостями. Ничего про глобальное прекращение разработки не упоминалось. Так же слежу за твиттерами людей, работающих с/для этой платформы.

Про Электрон не знаю ничего. И пока не очень привлекает. На мой взгляд какой-то очередной странный зигзаг индустрии. Как Air.
% java -jar logfx.jar 
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/athaydes/logfx/LogFX : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
...

Интересно, это только у меня на openSUSE Leap 42.3, или у всех с примером из статьи?
Портабилити не совсем впечатляет...:(
Видел такую ошибку при запуске scenebuilder. Нужна более высокая версия java. 52 это 8я java как я понял.
Приложение скомпилировано для java_ver>=java 8
Портабилити не совсем впечатляет...:(

Портабилити — это переносимость между платформами. Также есть понятие обратной совместимости — когда некое приложение скомпилированное на старой версии платформы продолжает работать на новой версии. А вот такое, что бы что-то скомпилированное на новой продолжало работать на старой версии, часто не бывает, ибо новое, оно потому и новое, что там что-то добавлено. Как же оно будет работать на старой версии если там этого нового ещё не было?!
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.