Скажи «нет» Electron! Пишем быстрое десктопное приложение на JavaFX

https://sites.google.com/a/athaydes.com/renato-athaydes/posts/saynotoelectronusingjavafxtowriteafastresponsivedesktopapplication
  • Перевод
  • Tutorial
В последнее время на программистских форумах развернулись неслабые дискуссии (для примера см. здесь, здесь и здесь, и эта сегодняшняя) об Electron и его влиянии на сферу разработки десктопных приложений.

Если вы не знаете Electron, то это по сути веб-браузер (Chromium) в котором работает только ваше веб-приложение… словно настоящая десктопная программа (нет, это не шутка)… это даёт возможность использовать веб-стек и разрабатывать кросс-платформенные десктопные приложения.

Самые новые, хипстерские десктопные приложения в наше время сделаны на Electron, в том числе Slack, VS Code, Atom и GitHub Desktop. Необычайный успех.

Мы писали десктопные программы десятилетиями. С другой стороны, веб только начал развиваться менее 20 лет назад, и на протяжении почти всего этого времени он служил только для доставки документов и анимированных «гифок». Никто не использовал его для создания полноценных приложений, даже самых простых!

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

Здесь не столько результат превосходства веб-стека для создания приложений (он далёк от такого превосходства, и вряд ли кто-то будет спорить, что веб — это бардак), сколько провал существующих фреймворков для разработки UI на десктопах. Если люди предпочитают отгружать со своими программами целый веб-браузер только для того, чтобы использовать отличные инструменты вроде JavaScript (сарказм) для разработки, что-то пошло совершенно не так.

Так что это за ужасные альтернативы, которые проиграли конкурентную борьбу веб-стеку?

Я решил взглянуть и создать реальное приложение на одной из этих технологий.

Альтернативы Electron


Ели вы не возражаете, что несколько групп разработки будут создавать разные версии приложения под разные ОС, то варианты выглядят примерно так: AppKit для MacOS, WPF для Windows (я не специалист по разработке под конкретные платформы, так что дайте знать, пожалуйста, какие варианты в наши дни более популярны).

Однако реальные конкуренты Electron — это мультиплатформенные фреймворки. Думаю, среди них самыми популярными сегодня являются GTK+, Qt и JavaFX.

GTK+


GTK+ написан на C, но связан со многими другими языками. Этот фреймворк использовался для разработки прекрасной платформы GNOME-3.

Qt


Qt кажется самой популярной альтернативой Electron в дискуссиях, которые попадались мне на глаза… Это библиотека C++, но тоже связанная с другими языками (хотя кажется, что никакие из них не поддерживаются на коммерческой основе, и сложно сказать, насколько они доработаны). Qt вроде бы популярный выбор для встроенных систем.

JavaFX


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

Что бы вы ни думали о JVM, не существует никакой другой платформы (кроме, может быть, самого Electron!), настолько простой для кросс-платформенной разработки. Как только вы создали свой jar, на любой платформе, вы можете распространять его среди пользователей всех ОС — и он просто будет работать.

При большом разнообразии языков, которые сейчас поддерживаются в JVM, выбор языка тоже не должен стать проблемой: определённо найдётся такой, какой вам понравится (в том числе JavaScript, если вы не способны от него отказаться), и вы можете использовать JavaFX с любым языком JVM без особых проблем. В этой статье, кроме Java, я покажу немного кода на Kotlin.

Сам UI создаётся просто кодом (если у вас есть замечательная поддержка IDE от IntelliJ, Eclipse или NetBeans: это всё отличные бесплатные IDE, которые, наверное, превосходят любых конкурентов и, кстати, представляют собой самые лучшие образцы десктопных приложений на Java) или в визуальном конструкторе UI: SceneBuilder (который умеет интегрироваться в IntelliJ) или NetBeans Visual Debugger.

История JavaFX

JavaFX — не новая технология. Она появилась в декабре 2008 года и сильно отличалась от того, что мы видим сегодня. Идея заключалась в создании современного фреймворка UI для замены устаревшего Swing Framework, который являлся официальным фреймворком JVM с конца 90-х.

Oracle чуть не испортила всё с самого начала, приступив к созданию особого, декларативного языка, который предполагалось использования для создания UI приложений. Это не очень хорошо восприняли Java-разработчики, и та инициатива чуть не погубила JavaFX.

Заметив проблему, Oracle решила выпустить JavaFX 2 в 2011 году без собственного особого языка, а вместо этого применив FXML в качестве опции для чистого Java-кода (как мы увидим позже).

Около 2012 года JavaFX обрёл некую популярность, а Oracle приложила значительные усилия для улучшения и популяризации этой платформы. С версии 2.2 фреймворк JavaFX стал достаточно цельным фреймворком, но его по-прежему не включали в стандартную среду выполнения Java (хотя он всегда поставлялся вместе с JDK).

Только с версии JavaFX 8 (изменение версии сделано для соответствия Java 8) он стал частью стандартного рантайма Java.

Сегодня фреймворк JavaFX может и не является крупным игроком в мире UI, но на нём сделано немало реальных приложений, у него есть довольно много связанных библиотек и его портировали на мобильную платформу.

Создание приложения JavaFX


В своём приложении для просмотра логов LogFX, я решил просто использовать Java (потому что там в основном довольно низкоуровневый код, а я хотел сконцентрироваться на скорости и малом размере пакета) и IntelliJ в качестве IDE. Я почти решился писать на Kotlin, но поддержка Java в IntelliJ оказалась настолько хорошей, так что писать на Java (точнее, позволить IntelliJ делать это за меня — это ближе к истине) стало не такой большой проблемой, чтобы оправдать лишние 0,9 МБ в дистрибутиве.

Я решил не использовать FXML (язык описания GUI для JavaFX на основе XML) или визуальный конструктор UI, потому что интерфейс у программы очень простой.

Итак, посмотрим на какой-нибудь код!

Java Hello World


Приложение JavaFX — это просто класс, который расширяет javafx.application.Application и показывает JavaFX Stage.

Вот как пишется Hello World на JavaFX:

 public class JavaFxExample extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         Text helloWorld = new Text("Hello world");
         StackPane root = new StackPane(helloWorld);
         primaryStage.setScene(new Scene(root, 300, 120));
         primaryStage.centerOnScreen();
         primaryStage.show();
     }

     public static void main(String[] args) {
         launch(JavaFxExample.class, args);
     }
 }
src/main/java/main/JavaFxExample.java

На «маке» этот код покажет примерно такое:



FXML+Java Hello World


Если вам трудно писать код для UI и вы предпочитаете использовать язык разметки, вот эквивалент того же кода с FXML:

 <?xml version="1.0" encoding="UTF-8"?>

 <?import javafx.scene.layout.StackPane?>
 <?import javafx.scene.Scene?>
 <?import javafx.scene.text.Text?>
 <Scene xmlns="http://javafx.com/javafx"
        width="300.0" height="120.0">
     <StackPane>
         <Text>Hello world</Text>
     </StackPane>
 </Scene>
src/main/resources/main/Example.fxml

 public class JavaFxExample extends Application {

     @Override
     public void start(Stage primaryStage) throws Exception {
         Scene scene = FXMLLoader.load(getClass().getResource("Example.fxml"));
         primaryStage.setScene(scene);
         primaryStage.centerOnScreen();
         primaryStage.show();
     }

     public static void main(String[] args) {
         launch(JavaFxExample.class, args);
     }
 }
src/main/java/main/JavaFxExample.java

Обратите внимание, что IntelliJ поддерживает FXML и свяжет его содержимое с соответствующим кодом Java и наоборот, подсветит ошибки, сделает автодополнение, справится с импортом, покажет встроенную документацию и так далее, что довольно круто… но как я раньше сказал, решено было не использовать FXML, поскольку задуманный UI был очень простым и довольно динамичным… так что я больше не покажу кода FXML. Если интересно, изучите руководство по FXML.

Hello World на Kotlin+TornadoFX


Прежде чем двигаться дальше, давайте посмотрим, как такой код выглядит на современном языке вроде Kotlin с его собственной библиотекой для написания приложений JavaFX, которая называется TornadoFX:

 class Main : App() {
     override val primaryView = HelloWorld::class
 }

 class HelloWorld : View() {
     override val root = stackpane {
         prefWidth = 300.0
         prefHeight = 120.0
         text("Hello world")
     }
 }
src/main/kotlin/main/app.kt

Многим может показаться привлекательным использовать Kotlin и JavaFX, особенно если вы предпочитаете безопасность типов (в TornadoFX есть приятная функция «типобезопасные таблицы стилей») и если добавить лишние 5 МБ в приложения для вас не проблема.

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

Стили и темы для пользовательского интерфейса JavaFX


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

Также как существуют различные подходы к макетированию, существуют и разные варианты стилей для JavaFX.

Предположим, что мы хотим сделать тёмный фон и белый текст, как показано на скриншоте:



Программные и встроенные стили


Один из вариантов (мучительный, но зато с безопасными типами) — сделать это программным способом:

 root.setBackground(new Background(new BackgroundFill(
         Color.DARKSLATEGRAY, CornerRadii.EMPTY, Insets.EMPTY)));

 helloWorld.setStroke(Color.WHITE);

Более простой программный способ — установить стили в CSS:

 root.setStyle("-fx-background-color: darkslategray");
 helloWorld.setStyle("-fx-stroke: white");

Обратите внимание, что здесь IntelliJ опять обеспечивает автодополнение для значений строк.

Если вы используете FXML:

 <StackPane style="-fx-background-color: darkslategray">
     <Text style="-fx-stroke: white">Hello world</Text>
 </StackPane>

То же самое…

Использование отдельных таблиц стилей


Если вы не хотите удаляться от мира веба и предпочитаете задавать стили в отдельных таблицах стилей, JavaFX и это умеет! Именно такой подход я выбрал, потому что он позволяет стилизовать всё в одном месте и даже даёт пользователям возможность выбирать стили на свой вкус.

Для этого сначала создаём таблицу стилей:

 .root {
     -fx-base: darkslategray;
 }

 Text {
     -fx-stroke: white;
 }
src/main/resources/css/hello.css

Теперь добавляем её в Scene:

 primaryStage.getScene().getStylesheets().add("css/hello.css");

И всё.

Заметьте, что таблицы стилей устанавливают не только фоновый цвет StackPane как darkslategray, но и меняют основной цвет темы.

Это значит, что все управляющие элементы и «фоновые» элементы примут цвет, основанный на этом цвете. Довольно изящная функция, потому что вы можете устанавливать цвета на базе основного цвета. Так вы гарантируете, что если изменить основной цвет, то практически всё будет хорошо выглядеть в новой расцветке.

Например, в нашем случае более подходящим цветом текста станет не белый, а «противоположный» цвет относительно основного цвета темы, чтобы текст всегда оставался читаемым:

 -fx-stroke: ladder(-fx-base, white 49%, black 50%);

Таблицы стилей JavaFX довольно умные, для дополнительной информации см. CSS Reference Guide.

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


Слева: стили по умолчанию JavaFX. Справа: кастомные стили, созданные выше

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

Вот как LogFX выглядит в итоге с темой по умолчанию:



Обратите внимание, что для кнопок я использовал иконки FontAwesome. Было довольно просто стилизовать кнопки в CSS. Просто убедитесь в том, чтобы шрифт устанавливался как можно раньше с помощью такой инструкции:

 Font.loadFont( LogFX.class.getResource( "/fonts/fontawesome-webfont.ttf" ).toExternalForm(), 12 );

С кастомными таблицами стилей можно кардинально изменить внешний вид приложения. Например, вот очень зелёная тема в Linux Mint:



Хотя хороший вкус автора этой зелёной темы под вопросом, она показывает мощные возможности стилизации в JavaFX. Здесь вы можете реализовать практически всё, на что способно ваше воображение.

В завершение хотел бы упомянуть классные эффекты, которые есть в JavaFX… Я хотел сделать начальный экран, который бы хорошо выглядел просто с форматированным текстом.

В JavaFX это делается просто. Вот что у меня получилось (я сделал экран на основе образца GroovyFX):



И вот какая таблица стилей соответствует этому стартовому экрану:

 Text {
     -fx-fill: white;
 }

 #logfx-text-log {
     -fx-font-family: sans-serif;
     -fx-font-weight: 700;
     -fx-font-size: 70;
     -fx-fill: linear-gradient(to top, cyan, dodgerblue);
 }

 #logfx-text-fx {
     -fx-font-family: sans-serif;
     -fx-font-weight: 700;
     -fx-font-size: 86;
     -fx-fill: linear-gradient(to top, cyan, dodgerblue);
     -fx-effect: dropshadow(gaussian, dodgerblue, 15, 0.25, 5, 5);
 }

Здесь возможно создание очень неплохих эффектов. Для дополнительной информации см. руководство.

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

Дизайн, отладка и перезагрузка кода


Практически невозможно создавать интерфейс пользователя без возможности мгновенно просматривать изменения. Поэтому важной частью любого фреймворка UI является «горячая» перезагрузка кода или некая разновидность конструктора UI.

У JavaFX (и у самой JVM) есть несколько вариантов решения этой проблемы.

SceneBuilder


Первое из них — это SceneBuilder, визуальный конструктор UI, который позволяет создавать FXML, просто перетаскивая компоненты UI.



Его можно интегрировать в любые Java IDE, что упрощает создание новых видов (экранов).

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

Если вы так сделаете, а потом откроете вид в SceneBuilder, он по-прежнему будет нормально работать, так что можно поочерёдно редактировать код вручную или в SceneBuilder — и просматривать результат.

ScenicView


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

Представьте это как эквивалент инструментов разработчика в браузере.



Для запуска ScenicView со своим приложением просто скачайте jar и передайте параметр -javaagent:/path-to/scenicView.jar в JVM.

ScenicView позволяет изменять и удалять узлы, отслеживать события и читать документацию Javadocs для выбранных элементов.

Горячая перезагрузка кода JVM


Если хотите изменить код приложения, который напрямую не связан с UI, то длоя этого подходит отладчик Java с горячей заменой кода во время работы приложения. Базовая поддержка перезагрузки кода имеется в Oracle JVM и HotSpot. Думаю, что она есть и в OpenJDK JVM.

Однако базовая поддержка этой функции очень ограничена: вам позволено менять только реализацию уже существующих методов.

Зато есть расширение HotSpot VM под названием DCEVM (Dynamic Code Evolution VM) с гораздо большей функциональностью: добавление/удаление методов и полей, добавление/удаление классов, изменение значения итоговых переменных и прочее. В другой статье я уже писал о нём и о других способах перезагрузки кода в работающей JVM.

Я использовал это расширение при разработке LogFX — и оно отлично себя проявило. Если не закрыть и заново не открыть окно, то вид не меняется автоматически при перезагрузке кода, но это не такая большая проблема, если менять что-то в Stage… к тому же, если вы хотите изменить только компонент UI, то можно использовать ScenicView или просто вернуться в ScenicBuilder и как угодно поменять дизайн.

Для запуска DCEVM нужно только установить его и сверить номера версий расширения и JVM. После этого приложение запускается с отладчиком — и каждый раз после перекомпиляции в IDE новый код автоматически подгрузится в работающую программу.

В IntelliJ после изменения класса и перекомпиляции вы увидите нечто подобное (Cmd+F9 на «маке»):



Обновление таблиц стилей


JavaFX не обновляет автоматически таблицы стилей. Но для LogFX я хотел сделать такую возможность, чтобы можно было изменять стили — и немедленно наблюдать эффект в приложении.

Поскольку LogFX — программа для просмотра логов, у неё довольно продвинутый FileChangeWatcher, который подходит для просмотра стилей и их перезагрузки.

Но он работает только если стили поставляются из отдельного файла, а не из самого приложения (из jar).

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

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

Для выбора таблицы стилей как файла (в отличие от ресурса jar), к сожалению, придётся использовать разный синтаксис под Unix/Mac и Windows. Вот такой метод я применил, чтобы решить проблему:

 private static String toAbsoluteFileUri( File file ) {
     String absolutePath = file.getAbsolutePath();
     if ( File.separatorChar == '\\' ) {
         // windows stuff
         return "file:///" + absolutePath.replace( "\\", "/" );
     } else {
         return "file:" + absolutePath;
     }
 }

Это работает на Mac, Windows и Linux Mint. Но это только первая из двух проблем, которые возникают на разных ОС (вторая — то, что не отображается иконка в системном трее на Mac, хотя есть уродливое обходное решение этой проблемы). В остальном JavaFX всё абстрагирует довольно хорошо по большей части.

Наконец, когда диспетчер определил изменение в файле с таблицами стилей, вы можете обновить стиль, просто удалив его и немедленно добавив обратно:

 Runnable resetStylesheet = () -> Platform.runLater( () -> {
     scene.getStylesheets().clear();
     scene.getStylesheets().add( stylesheet );
 } );

Такой метод неплохо работает. Но если вы не хотите сами его писать, то ScenicView тоже умеет отслеживать таблицы стилей во внешних файлах (но не внутри jar), и TornadoFX тоже это поддерживает, так что здесь есть варианты.

Заключение


Создание приложения на JavaFX стало довольно приятным опытом. У меня имелась некоторая практика написания JavaFX-приложений для работы несколько лет назад (когда JavaFX находился на ранней стадии развития, что теперь уже осталось в прошлом), так что у меня определённо была некая фора… но я также работал как веб-разработчик и теперь не могу поверить, что кто-то предпочтёт использовать веб-стек вместо такой вменяемой среды как JVM.

Созданное приложение LogFX, на мой взгляд, работает очень хорошо, и оно достигло поставленных целей по скорости работы и быстрому отклику, и в то же время оно хорошо выглядит на всех операционных системах без внесения изменений. Пожалуйста, посмотрите сами и выскажите свой мнение:

curl -sSfL https://jcenter.bintray.com/com/athaydes/logfx/logfx/0.7.0/logfx-0.7.0-all.jar -o logfx.jar

Хотя это полностью функциональное приложение, файл jar весит всего 303 килобайта. Это 0,3 МБ, включая несколько картинок и файл шрифта TTF, и ещё несколько файлов HTML и CSS, помимо файлов классов Java!

Конечно, приложение не включает саму виртуальную машину JVM, но JVM не является частью программы и может использоваться для многих приложений! В Java 9 вы можете вообще создавать нативные исполняемые файлы, включая в них только необходимые части JVM, так что если вашим пользователям не нравится простой jar, то упакуйте его как нативное приложение, как я показывал в предыдущей статье (небольшое нативное приложение JVM займёт примерно 35 МБ или 21 МБ после оптимизации).

Для работы LogFX требуется около 50 МБ RAM (не для самого приложения, а в основном для JavaFX). В этом можно убедиться, запустив программу такой командой:

java -Xmx50m -jar logfx.jar

Это кардинально отличается от приложений Electron, которые обычно жрут 200 МБ уже в момент запуска.

JavaFX не идеальна и есть много областей, которые всё ещё нуждаются в улучшении. Одна из них — распространение и автоматическое обновление программ. Текущее решение, JNLP и Java WebStart, кажется слабо реализованным, хотя имеются альтернативы от сообщества, такие как Getdown и FxLauncher, а если вы хотите правильный нативный инсталлятор, то имеется и коммерческое решение Install4J (кстати, у Install4J есть бесплатные лицензии для проектов open source).

Осталось много вещей насчёт JavaFX, которые у меня не нашлось времени упомянуть в этой и так уже длинной статье, но некоторые из них, я считаю, достойны дополнительного изучения, если вам интересно:

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 183
  • +17
    Мне кажется, что для корректного сравнения все же стоило добавить так же часть разработки точно такого же приложения на Electron. И в конце все же их стоит сравнить, а так же сравнить при возможности скорость разработки такого приложения.
    • +2

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                  пруф линк?
                                • +9

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

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

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

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

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

                                      • 0

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

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

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

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

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

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

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

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

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

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

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

                                            • 0
                                              Верно, обертка(не уточнил), но так как конечный пользователь хочет видеть у себя на рабочем столе .exe, а не .jar, то это полезный инструмент и прямо из сборщика проекта.
                                          • +2
                                            Самые новые, хипстерские десктопные приложения в наше время сделаны на Electron, в том числе Slack, VS Code, Atom и GitHub Desktop.
                                            Если первые три еще вполне терпимые приложения, то Github Desktop — самое настоящее вселенское (и дико медленное) зло.
                                            • +1
                                              имею очень широкий опыт разработки десктопного приложения на 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 — задобает количеством сборок для всех платформ
                                              • 0
                                                А под какие задачи «надо» писать десктоп на Java?
                                                • +1
                                                  да хотя бы толстые клиенты для серверного софта
                                                  • +1
                                                    Под любые. Хоть текстовый редактор, хоть торрент-качалка, хоть что.

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

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

                                                      • 0

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

                                                        • 0
                                                          А он нужен для разработки или для запуска получившегося jar тоже?
                                                          • 0
                                                            Если я ничего не путаю, там тупо запакованы javax, нужные для запуска.
                                                            JavaFX is not part of the ARM JRE
                                                          • +1
                                                            Угу. Без веба. Очень старой версии (был, сейчас е знаю). И не запускался, т.к. нужно было либу дособирать.
                                                          • 0
                                                            почему же нет?
                                                            скриншот
                                                            image
                                                            • 0
                                                              Потому что нормальной свежей версии без костылей и с вебом нет.
                                                              • 0
                                                                веб работает, вот скриншот моего майл клиента на java fx, компонент WebView
                                                                а о каких костылях идёт речь?
                                                                скрин с вебом
                                                                image
                                                        • +5
                                                          Позвольте внести свои 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 не вызывает.
                                                          • +1
                                                            А, если не секрет, из-за какой цены отпал Qt?
                                                            • 0
                                                              Почему же секрет — вот www1.qt.io/buy-product

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                        В Android'е эту проблему решили «ручным» OOM-киллером: процессы убиваются до того, как система «встанет колом». Но на десктопе соотвествующего watchdog'а нет, потому своп должен быть…
                                                                                        • 0
                                                                                          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) могут вытеснить страницы, занимаемые кодом, даже при отсутствии своп файла\раздела.
                                                                                        • 0
                                                                                          Нет, даже в винде, где своп вылизали как могли >10% оперативки в свопе замедляют работу.

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

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

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

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


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


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


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


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


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

                                                                            • +1

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

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

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

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

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

                                                                                • 0

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

                                                                              • 0
                                                                                Продуктами от JetBrains не пользуетесь?
                                                                                • 0
                                                                                  Вот именно поэтому )
                                                                              • –9
                                                                                Один хипстер обвиняет других что они хипстеры, нет нечего лучше чем 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 очень прожорливая, так что если потребление ресурсов не является ключевым, то эта «технология» подойдет. Но выражения автора статьи меня подвергли к написанию такого вот объемного текста, не люблю когда кто-то преподносить технологию как панацею, это не профессионально просто.
                                                                                • +2
                                                                                  > да и плюс машина JVM очень прожорливая

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

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

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

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

                                                                                    • +2
                                                                                      Веб, при всей своей ужасности породил очень удобные инструменты отладки вёрстки, и множество других инструментов. Такой удобный дебаггер как хром дев тулз ещё поискать нужно в других экосистемах. Я не только про отладку именно кода, хотя и там асинк коллстеки это нереально круто, но и инспектор dom и удобство его модификации, и профайлер с таймлайном и куча других вещей на расстоянии клика. И интерфейсов в вебе верстается сейчас не в пример больше, и опыт там копится быстрее.
                                                                                      • +1
                                                                                        Конкурентом Electron можно считать Sciter — HTML + CSS + JS-like script. Написан на С++, не требует JVM и прочих зависимостей. Отлично интегрируется с бизнес-логикой на С++.
                                                                                      • 0
                                                                                        На JavaFX можно и JS использовать.
                                                                                        • +2
                                                                                          Главная причина, почему Electron настолько популярен: не нужно переписывать уже написанное. Имея уже веб приложение, вам не потребуется много сил для натягивания его на Electron. Если же делать десктопное приложение с 0, то вам не придется искать новых специалистов. Берем имеющихся веб-разработчиков и усаживаем их за Electron и кошелек доволен и скорость разработки высокая. Например, тот же Slack так и поступил. Про легкость создания и настройки UI говорить не стоит.
                                                                                          Главным же недостатком Electrone является его прожорливость и большой вес даже минимального приложения. Я вижу такой путь к решению проблемы: завозим Electron в качестве VM, а exe-шник приложения по сути его запускает и скармливает нужные данные. И получаем сразу -90% от общего веса приложения (даже если от проблем с ОЗУ это спасет не особо, то компактность увеличит значительно), а о проблеме с ОЗУ надо уже отдельно думать.
                                                                                          • 0
                                                                                            Потом к этой виртуальной машине нужно приделать инпут-онмнибокс, в котором можно указать URL «программы» и… получим браузер.
                                                                                            • 0

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

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

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

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

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

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

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

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

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