Если вы не знаете 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);
}
}На «маке» этот код покажет примерно такое:
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> 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);
}
}Обратите внимание, что 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")
}
}Многим может показаться привлекательным использовать 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;
}Теперь добавляем её в
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, которые у меня не нашлось времени упомянуть в этой и так уже длинной статье, но некоторые из них, я считаю, достойны дополнительного изучения, если вам интересно:
- Привязывание свойств позволяет легко внедрять реактивные UI.
- Диаграммы на JavaFX выглядят великолепно.
- Поддержка 3D в JavaFX.
- Тестировочные фреймворки для JavaFX: TestFX и Automaton (дисклеймер: я являюсь автором Automaton и работал с командой, которая изначально разработала TestFX).
- Демо-приложения JavaFX Ensemble показывают бoльшую часть возможностей JavaFX в реальной работе.
Комментарии (163)
Smerig
05.10.2017 11:08+10Для нас Electron хорошая альтернатива, т.к. у нас есть куча кода, написаного на js/html/css, который используется на сайте. Чтобы не пришлось все это дело переписывать, взяли электрон.
quwy
06.10.2017 00:39+1И переложили свои проблемы на юзера. Пусть сам теперь память докупает, чтобы какой-нибудь примитивный чятик на электроне смог сожрать свой гигабайт.
DrPass
06.10.2017 01:05+7Как программист я вас отлично понимаю. Это здорово — иметь одну кодовую базу и писать приложение один раз под все платформы. Я сам так делаю в некоторых наших проектах.
А как пользователь, я эти вечно запинающиеся полувеб-приложения, и тех, кто их пишет, ненавижу. И себя тоже :)
indestructable
05.10.2017 11:23-3Хотя веб, конечно, тот еще бардак, у него есть два огромных преимущества:
- веб много лет эволюционировал для разработки UI. В результате в нем есть классные подходы типа FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке (кроме React Native).
- компонуемость: практически нет ограничений на содержимое элемента, поэтому можно довольно легко делать очень сложные вещи, типа тех же гридов.
Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?
Единственный, на мой взгляд, реальный конкурент веб-подходам на десктопе — это мобильные приложения, но им еще долго догонять веб-приложения по удобству разработки.
Free_ze
05.10.2017 11:55+7Единственный, на мой взгляд, реальный конкурент веб-подходам на десктопе — это мобильные приложения
«Земля тряслась — как наши груди, Смешались в кучу кони, люди, И залпы тысячи орудий.»
clayLain
05.10.2017 12:09+4В результате в нем есть классные подходы типа FRP
Qt включает в себя язык QML который поддерживает биндинги.
Как я понимаю это то FRP о котором вы говорите.
Vadem
05.10.2017 12:57FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке
FRP на десктопе уже давно.
Например, ReactiveUI появился ещё в 2010 году и, думаю, он был далеко не первым.
j_wayne
05.10.2017 13:10+13> Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?
Вы, конечно же, шутите? Даже в предшественниках — AWT, Swing и если немного в сторону, у SWT, все это было в полный рост, цвело и пахло (как и у любой достаточно продвинутой GUI системы), когда веб пешком под стол еще ходил. Более того, все это делается гораздо проще.
m52
05.10.2017 11:26+16Судя по тому, что я видел на javafx, если говорить о ресурсоемкости приложений, это один из тех случаев, когда ДАЖЕ электрон лучше.
LemToUp
05.10.2017 11:36+5Думаю электрон начал набирать обороты из-за того что увеличились свободные ресурсы в трафике и производительности. (Скачать 10 — 30mb установочник уже не проблема. Мобилки тоже перестали безбожно тормозить).
Ну а популярнее станет тот, в котором быстрее кодить и который прощает больше говнокода)Huan
05.10.2017 12:09+3К Вашему могу добавить еще то, что и яваскрипт машины стали на порядок быстрее
quwy
06.10.2017 02:23+1электрон начал набирать обороты из-за того что...
… в индустрию хлынуло 100500 хипстоты, которая кроме жабаскрипта ничерта не знает и знать не хочет.YChebotaev
06.10.2017 03:35+1Ну, я, типа, хипстота, которая на жабаскрипте пишет. До этого писал на плюсах, на питоне, на похапе. Ответственно заявляю, что на жиэсе лучше всего гуи делать.
quwy
06.10.2017 15:55-2Из перечисленного — возможно, особенно питон с похапе показательно. Что касается плюсов, то сильно зависит от фреймворка и среды разработки. Если делать все на WinAPI, то и хтмл раем покажется.
YChebotaev
08.10.2017 16:53А вы на чем таком пишете, что все основные технологии вам не нравятся? Расскажите, я тоже такой инструмент освоить хочу.
quwy
09.10.2017 19:33все основные технологии вам не нравятся?
Основные? Для чего они основные? Топик о десктоп-приложениях, каким боком тут PHP с Питоном вообще? Да, я знаю, что и там и там можно писать десктоп, но это не делает данные инструменты основными. Плюсы с QT на порядок приятнее, чем язык гипертекстовой разметки, VCL — на два порядка приятнее, пусть и не кроссплатформа.
ALexhha
08.10.2017 21:46Думаю электрон начал набирать обороты из-за того что увеличились свободные ресурсы в трафике и производительности.
я когда вижу, как скайп на моем ноуте под линухом отъедает 3 Гб и 100% процессора, так и хочется увидеть этих программистов и высказать им все, что я о них думаю. Помогает только перезапуск скайпа.
Terras
05.10.2017 11:53+4Не хочу омрачать такой пост, но на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.
Он говорит, что изначально проект вообще хотели закрыть, но потом передумали и просто «заморозили его».
Я к тому, что нефиг выпендриваться. Java — это веб-морда, хочешь писать десктоп (натив, глючные электроны или тяжеловесный QT)Free_ze
05.10.2017 12:00+9тяжеловесный QT
Когда рядом в предложении стоит электрон и Java, Qt становится маленьким и юрким.Terras
05.10.2017 12:01-5я к тому, что писать на нем достаточно проблематично. Ну если, конечно, не использовать обертку в виде PyQT
Free_ze
05.10.2017 12:14+5Если исходить из того, что разработчик уже нанят и знает свой инструмент, то не настолько уж сложно. Тем более, что для фронта есть QML.
VioletGiraffe
05.10.2017 14:08+3PyQt — костыль, потому что Qt — это С++ фреймворк. Писать на нём очень просто, и он совсем не тяжеловесный. Легче может быть только нативный, не кросс-платформенный бинарник (а свой Питон вы в вес приложения не забыли посчитать, нет?).
yetanothercoder
05.10.2017 20:06+1но на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.
пруф линк?
k12th
05.10.2017 11:57+9Думаю, таких статей можно написать по числу языков программирования. Каждый пишет на том, что знает. Никто не будет изучать Java и JavaFX/C# и WPF/Лелика и Болика только чтоб написать одноразовый просмотрщик логов с полутора юзерами, все сделают на том, что знают.
arku
05.10.2017 12:09+3Вы написали Hello World по сути, а уже потребовалось использовать костыли для поиска стилей на разных ОС. Что же ждет нас дальше?
kekekeks
05.10.2017 12:52+2Я вот добавил в html-ый текстовый
inputpadding-left: 20pxи пришлось использовать костыли для работыwidth: 100%. Что же ждёт нас дальше?
Tibor128
05.10.2017 12:19а про xul никто и не вспомнил… имхо перспективная штука… была =(
или я что-то перепутал?k12th
05.10.2017 12:25+2Перспективную эту штуку щас добивают в мозилле:)
Tallefer
06.10.2017 15:48Что забавно, был момент, когда XUL играл точно ту же роль, что и электрон сейчас. Навскидку припоминаю какой-то перекодировщик видео, который использовал вебморду для интерфейса через XUL, а до или после того — эмбеддед ИЕ, кажется. Был еще то ли плагин для ФФ, то ли отдельное приложение, называлось Prism, это вот как раз как электрон почти было, для построения десктоп софта.
k12th
06.10.2017 15:51Я не помню, чтобы у кого-то баттхертило (наверное потому что я тогда еще не ходил linux.org.ru) от XUL.
Да софта на нем было было не в пример меньше.Tallefer
06.10.2017 16:24Ну видимо, это и было причиной. :) Тупо некому было.
Проблемы были почти те же (многовато жрет, прилагивает), только пропорционально меньше.
Зато дико перло поначалу, скажем, яндекс-карты обернуть в призму и ярлыком на стол, а в ярлык еще и координаты запихать.
jSergeyNik
05.10.2017 12:42+1Приложение JavaFX можно скомпилировать в нативное приложение с помощью Gradle плагина:
github.com/FibreFoX/javafx-gradle-plugin
www.youtube.com/watch?v=7n41K2GT9YY
Пробовал компилировать для Windows и Linux — успешно.
Все красивости делаются с помощью CSS
Beholder
05.10.2017 13:07Справедливости ради, это никакое не "нативное" приложение, а только обёртка для вызова утилиты
javapackagerиз JDK, которая упаковывает приложение и JVM в один exe-файл. Хотя для пользователя разница невелика.j_wayne
05.10.2017 13:14+1Причем, распространять приложение вместе с таким JRE совершенно легально, если вы ничего там не меняете. Пруф с ходу не дам, но вопрос изучал в свое время, была такая необходимость.
JDK 9 в теории может повыбрасывать оттуда все неиспользуемое и футпринт будет уже совсем не в пользу Electron. На практике я это пока не пробовал.
poxvuibr
05.10.2017 16:36+2JDK 9 в теории может повыбрасывать оттуда все неиспользуемое и футпринт будет уже совсем не в пользу Electron
Собрал hello world c javafx и выбросил всё лишнее. Получилось приложение + standalone jvm. 44 мегабайта
jSergeyNik
05.10.2017 13:43Верно, обертка(не уточнил), но так как конечный пользователь хочет видеть у себя на рабочем столе .exe, а не .jar, то это полезный инструмент и прямо из сборщика проекта.
fatronix
05.10.2017 12:42+2Самые новые, хипстерские десктопные приложения в наше время сделаны на Electron, в том числе Slack, VS Code, Atom и GitHub Desktop.
Если первые три еще вполне терпимые приложения, то Github Desktop — самое настоящее вселенское (и дико медленное) зло.
Terranz
05.10.2017 13:00+1имею очень широкий опыт разработки десктопного приложения на javafx 2
- стили это очень удобно — можно просто и быстро менять внешний вид, иконки и прочее
- fxml — очень крутая штука, как и в qt — qml. Можно отдать на откуп дизайнеру и всё,
сосредоточиться на коде - куча готовых примеров на все случаи жизни
- нет встроенных компонентов для диалогов и визардов, помогает controlsFX
- на всех платформах где есть java 8 будет выглядеть одинаково — win32\64 lin32\64, да даже на raspberry pi
- глюки в самом нужном компоненте — в таблице
- если надо писать gui для desktop java — то лучше не найти, swing — уныл, swt — задобает количеством сборок для всех платформ
Sap_ru
06.10.2017 03:31Ээээ… на всех платформах? Ну, вы же в курсе, что для ARM fx нет и не будет?
Terranz
06.10.2017 13:47почему же нет?
скриншот
j_wayne
05.10.2017 13:28+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 не вызывает.Alcor
05.10.2017 13:37+1А, если не секрет, из-за какой цены отпал Qt?
j_wayne
05.10.2017 13:43Почему же секрет — вот www1.qt.io/buy-product
А это причина, по которой OSS лицензия не подходила.
A commercial license keeps your code proprietary
peter_m
05.10.2017 14:47+1Ну тогда если не секрет, почему опенсорсную лицензию не рассматривали.
Available under GPL & LGPLv3 licenses
info.qt.io/download-qt-for-application-developmentj_wayne
05.10.2017 15:00Верно, LGPL вроде бы подходил, но там были нюансы с линковкой. Думаю, что я бы на этом на какое то время увяз, не имея опыта с Qt (и вообще в целом опыт с С++ только в далекие студенческие времена. Да и то скорее — опыты, а не опыт)). А времени было 2 недели на апп + бэкенд.
Да, вы правы, это был очень слабый аргумент. Или неверный.
Вообще, Qt меня очень привлекает с точки зрения ТТХ. Но как-то каждый раз с ним не срастается, слишком много нужно про него узнать.TargetSan
05.10.2017 17:27+2Если совсем коротко — линкуетесь с Qt динамически (фреймворк в отдельных DLL/SO) и творите что хотите. В своём коде конечно.
j_wayne
05.10.2017 13:40P.S. в то же время так противопоставлять Electron vs Java FX — это ИМХО несколько перебор.
Делаю хобби-проект с BLE 4.0. Тоже нужна небольшая программка, сидящяя в трее. С BLE 4.0 в Java довольно печально. Qt традиционно «не осилил», хотя честно пытался) А вот для node.js библиотека завелась с полтычка: github.com/sandeepmistry/noble. Если учесть, что мне еще нужны веб-сокеты для интеграции с внешним сервисом, а каких-то ограничений по размеру/производительности не стоит — выбор Electron выглядит вполне разумно.
DevAndrew
06.10.2017 02:22+1С BLE 4.0 в Java довольно печально.
А смотрели на таких ребят как Bluegiga? Есть у них такая библиотечка для BLE.j_wayne
06.10.2017 09:59Спасибо за линк, нет, не видел.
Смущает следующее: «All you need is a BLED112 dongle on a PC.». Это реализация API для конкретного адаптера?DevAndrew
09.10.2017 02:08Да, для группы адаптеров Bluegiga. Из тех решений на java, что я видел, это мне понравилось больше всех. Если кто то подскажет более идеальное и без привязки к адаптеру, буду премного благодарен.
rmerkushin
05.10.2017 14:21+1Боже упаси от десктоп приложения на Java!
zirix
05.10.2017 16:31А что не так с java?
Terras
05.10.2017 16:57-7Java — серверный язык. Он хорошо работает на определенных машинах, с определенным софтом (основным и вспомогательным), с хорошим прогревом и прочее.
Когда пытаешься все это перенести на машину обычного пользователя, получается какой-то ад, и практически 100% что-то будет отваливаться, тупить и приносить «радость», не говоря уже про обновления.izzholtik
05.10.2017 17:25+6Что за чушь?
Я пишу под десктоп на Java. И почему-то мои программы до ПОЛНОСТЬЮ рабочего состояния (т.е. никакой «активации модулей» при первом открытии меню, вся графика уже в кэше, пул соединений с БД инициализирован) запускаются за 5-10 секунд. И почему-то они работают и под виндой, хотя разрабатываю полностью на лине. И ничего не «тупит» и не «отваливается».
Возможно, я что-то делаю не так? Поделитесь пожалуйста опытом написания тормозного и глючного софта, будет очень интересно послушать.vsb
05.10.2017 19:10+7Запуск за 10 секунд это и есть тормозной софт. Не тормозной софт запускается за долю секунды.
zirix
05.10.2017 19:29+1Софт бывает разный. Для мощной IDE, например от JetBrains, 5-10 секунд это нормально.
7-10 секунд для веб сервера с фреймворком типа Spring и ORM — тоже не много.izzholtik
05.10.2017 19:49У меня Netbeans стартует секунд 40 и потом проекты открывает минуты две, хех. На Q9550 особо не побегаешь.
zirix
05.10.2017 20:16А у вас система(или JDK), IDE и проект лежит на SSD?
Если нет, то узким местом является HDD, а не процессор.izzholtik
05.10.2017 22:32+1Да, на SSD. Перенос ускорил сабж процентов на 25.
Собственно, на домашнем компьютере IDE за 15 секунд запускается, софтина — за 7, из которых 4 — кэширование графики и 1.5 — самотестирование и подобный трэш.
webkumo
06.10.2017 13:09А что у вас с оперативкой? И какая ОС (точнее важнее вопрос — отключён ли своп к ...)?
izzholtik
06.10.2017 21:45С оперативой всё плохо, она работает на 800 МГц.
Ось — бубунта. 16 с копейками.
Своп не отключен, я часто выхожу за имеющиеся 16 Гб. Я вообще считаю отключение свопа чем-то вроде спиливания прижин на автомобилях. Не надо его отключать.khim
06.10.2017 23:00Своп не отключен, я часто выхожу за имеющиеся 16 Гб.
Гроб. С музыкой. Докупить памяти и не мучаться.
К огромному сожалению Linux очень плохо работает со свопом. Потому что просто исторически считалось, что раз система ушла в своп — то всё уже и так очень плохо и можно «расслабиться». Появление SSD заставило людей задуматься об этом проблеме, но когда своп в Linux будет работать хотя бы сравнимо с тем, что в *BSD — науке неведомо.
webkumo
07.10.2017 11:24Хм… Нет, даже в винде, где своп вылизали как могли >10% оперативки в свопе замедляют работу. >50% делают её паталогически неспешной с подвисанием UI.
В линуксе своп не нужен от слова совсем, но менеджить доступный объём приходится руками — это да, непривычно. Впрочем я и на винде при наличии возможности отключаю своп.khim
07.10.2017 14:10Отключение свопа — это уж совсем странное действие. Типа как срезать ремень безопасности, чтобы почуствовать себя «настоящим пацаном».
Дело в том, что ни в Windows, ни в Linux вы не сможете отключить своп «по настоящему». Потому что странички, принадлежащие программе всегда могут «уйти в своп» (их можно выкинуть из памяти, так как всегда есть возможность загрузить их из оригинального файла). То есть если у вас начинает кончаться память при наличии свопа — система замедляется, если то же самое происходит при его отсутствии — она замедляется катастрофически.
В Android'е эту проблему решили «ручным» OOM-киллером: процессы убиваются до того, как система «встанет колом». Но на десктопе соотвествующего watchdog'а нет, потому своп должен быть…
lieff
07.10.2017 15:40en.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) могут вытеснить страницы, занимаемые кодом, даже при отсутствии своп файла\раздела.
sumanai
07.10.2017 16:32Нет, даже в винде, где своп вылизали как могли >10% оперативки в свопе замедляют работу.
Интересно, каким магическим образом память неактивных программ может вызвать хоть какие-то тормоза? Пусть даже там будет 10% памяти, если она не принадлежит активным процессам, вы заметите только ускорение за счёт большей свободной памяти для кеша и активных программ.webkumo
09.10.2017 16:56Процессом чтения-с-диска/записи-на-диск вестимо. Или у вас только ssd уже?
sumanai
09.10.2017 21:09Память неактивных сбрасывается один раз, память отображённых на память страниц просто переходит в список простаивающих и обнуляется. Так что SSD достаточно только для системы с подкачкой, и ни единого тормоза от подкачки неактивных процессов вы не заметите.
izzholtik
05.10.2017 19:33+1А чудес не бывает. Если для работы программы нужно загрузить данные, то она будет их загружать. В моём случае софт работает часами, так что "честная" инициализация выгоднее тормозов при использовании.
rmerkushin
06.10.2017 05:08+2Ну много ест памяти, требует зачастую JRE если не собрано с ним, тормозит и очень долго стартует если комп не самый быстрый и без SSD, ну и самое важное для меня чудовищно ест батарею на ноутбуке. Ушёл кстати от продукта JetBrains PyCharm на VS Code и не жалею.
rmerkushin
06.10.2017 05:19Да забыл добавить такой ещё косяк Java на маке был, за каким то лядом врубалась дискретка на ноуте и он грелся и шумел от этого. Не уверен но вроде не пофиксили.
Rinz
05.10.2017 14:21-9Один хипстер обвиняет других что они хипстеры, нет нечего лучше чем Smalltalk and Lisp family, а ваши детские языки с сахаром от которого диабет уже превысил все возможные нормы для жизни только усложняют жизнь, а не облегчают!
Пункт подрыва завершен, а теперь конкретнее:
- У Kotlin ужасная реализация параллельного программирования, т.е. я бы назвал ее вообще нет,
реализация паралелки через итераторы я считаю наркоманией - Сказать что сопрограммы/корутины наркоманские, не сказать нечего, вы видели его синтаксис? Блин,
по сравнению с ним С++ реализация кажется очень красивым и лаконичным - Чем вам .core C# не понравился кроме религиозной причины? Обилия сахара максимум, тут и async/await с пол пинка, тут и Thread/Task заводится без усилии, лаконичные делегаты и общирные возможности полиморфизма встроенных объектов ну и кроссплатформленный, покрайне мере проверял и запускается на каждом древнем тапке с Debian 6-7 на борту
Что бы вы ни думали о JVM, не существует никакой другой платформы (кроме, может быть, самого Electron!), настолько простой для кросс-платформенной разработки. Как только вы создали свой jar, на любой платформе, вы можете распространять его среди пользователей всех ОС — и он просто будет работать.
чушь, как минимум C# .core еще кидаем в копилку TCL and Smalltalk and Lisp Family and Haskell and Fortran and Rust and Golang and… Java не универсальный нож, а в истории выехала только за счет рекламы Sun
Итог, Kotlin отлично подойдет сделать что-то быстро и не заморачиваясь над деталями, синхронные приложения писать на нем можно как нечего делать, а вот как только понадобится решить задачи связанные с многопоточным выполнением, там отхлебнете, да и плюс машина JVM очень прожорливая, так что если потребление ресурсов не является ключевым, то эта «технология» подойдет. Но выражения автора статьи меня подвергли к написанию такого вот объемного текста, не люблю когда кто-то преподносить технологию как панацею, это не профессионально просто.j_wayne
05.10.2017 14:33+2> да и плюс машина JVM очень прожорливая
Слишком широкое заявление. По сравнению с чем? На каких задачах? При каких настройках/ограничениях? У меня rails worker'ы больше памяти потребляют, чем куда-более нагруженный java сервис. Но выводов каких-то я из этого не делаю. Задачи разные и решены по разному.
lumini
05.10.2017 15:32+1> Чем вам .core C# не понравился кроме религиозной причины?
Тем, что под него нет десктопного UI? AvaloniaUI пока в ясельном возрасте.
g0rdan
05.10.2017 16:59А как же Xamarin.Forms/WPF + XAML?
iOS, Android, Windows, Mac OS, Linux, даже никому не нужные Windows Phone и Tizen.
Я не удивлюсь если в течении полугода они принесут Forms в браузеры через WebAssembly (a.k.a реинкарнация SilverLight)lumini
05.10.2017 21:21Стоп, но что из перечисленного относится к теме кросплатформенных десктопных приложений? (статья про них)
g0rdan
05.10.2017 21:40Xamarin.Forms + Mac OS/Linux и в какой-то степени WPF + Windows. Конечно комбинация Forms + WPF не может считаться полностью кроссплатформенной для десктопов, но определенно есть множество общих знаменателей.
TheKnight
05.10.2017 22:42А можно ссылку на гуевое приложение на Xamarin.Forms работающее на Windows, MacOS и Linux?
Желательно (но не обязательно) с открытыми исходниками (чисто любопытство).
snrostov
05.10.2017 16:58У Kotlin ужасная реализация параллельного программирования, т.е. я бы назвал ее вообще нет, реализация паралелки через итераторы я считаю наркоманией
Вы смотрели https://kotlinlang.org/docs/reference/coroutines.html?
Что такое "реализация паралелки через итераторы"?
- У Kotlin ужасная реализация параллельного программирования, т.е. я бы назвал ее вообще нет,
Aquahawk
05.10.2017 14:36+2Веб, при всей своей ужасности породил очень удобные инструменты отладки вёрстки, и множество других инструментов. Такой удобный дебаггер как хром дев тулз ещё поискать нужно в других экосистемах. Я не только про отладку именно кода, хотя и там асинк коллстеки это нереально круто, но и инспектор dom и удобство его модификации, и профайлер с таймлайном и куча других вещей на расстоянии клика. И интерфейсов в вебе верстается сейчас не в пример больше, и опыт там копится быстрее.
xystarcha
05.10.2017 16:57+1Конкурентом Electron можно считать Sciter — HTML + CSS + JS-like script. Написан на С++, не требует JVM и прочих зависимостей. Отлично интегрируется с бизнес-логикой на С++.
csmile
06.10.2017 20:41Да, вот было бы интересно увидеть приложение аналогичное Sciter Notes на JavaFX:
У меня это заняло два месяца этим летом.
zede
05.10.2017 18:27+2Главная причина, почему Electron настолько популярен: не нужно переписывать уже написанное. Имея уже веб приложение, вам не потребуется много сил для натягивания его на Electron. Если же делать десктопное приложение с 0, то вам не придется искать новых специалистов. Берем имеющихся веб-разработчиков и усаживаем их за Electron и кошелек доволен и скорость разработки высокая. Например, тот же Slack так и поступил. Про легкость создания и настройки UI говорить не стоит.
Главным же недостатком Electrone является его прожорливость и большой вес даже минимального приложения. Я вижу такой путь к решению проблемы: завозим Electron в качестве VM, а exe-шник приложения по сути его запускает и скармливает нужные данные. И получаем сразу -90% от общего веса приложения (даже если от проблем с ОЗУ это спасет не особо, то компактность увеличит значительно), а о проблеме с ОЗУ надо уже отдельно думать.
barkalov
05.10.2017 18:46Потом к этой виртуальной машине нужно приделать инпут-онмнибокс, в котором можно указать URL «программы» и… получим браузер.
webkumo
05.10.2017 20:36Хм… Так это… Та же Idea умеет какие-то функции выбрасывать в локальный браузер… в чём тогда проблема вместо запуска толстого клиента вообще поднять локальный сервер, который будет работать с браузером?.. вряд ли это будет дороже, чем Electron...
zede
05.10.2017 21:25Не стоит забывать, что Eдectron не только Chromium, но и Node со всеми отсюда вытекающими: работа с файлами, взаимодействие с ОС. Поэтому слова, что мы получаем тот же браузер не совсем верны. А вот насчет надбраузера, так на нем его уже сделали: Brave(правда там форк Electron-а и цели несколько иные нежели чем у обычных браузеров).
Если уж кому-то совсем в край извратиться тот же сервер можно для управления обернуть Electron-ом(но это надо уж совсем извращенцем быть)
mrsantak
05.10.2017 23:58А такие решения уже есть. есть такая штука как cuba platform, так у них IDE это веб приложение поднимаемое на localhost'е.
Free_ze
05.10.2017 18:53-1Вообще странная идея — имея сайт волочь его на десктоп.
Про легкость создания и настройки UI говорить не стоит.
Легкость для кого? Весь ужас и ад инструментов современного веба приходит на десктопы?
point212
05.10.2017 22:43-5Сколько я ни пытался изучить Java, так и не смог его понять. Это просто какой-то вывих мозга. Наверное при обучении надо сначала свернуть себе мозг, чтобы он перевернулся в черепе. А потом уже можно спокойно писать.
Так много слов чтобы сделать простейшие действия. Сразу столько концепций, объектов, функций. Пипец…
TheKnight
05.10.2017 23:03А вы часом не справочник по Java читали?
Если вы только начинаете разбираться в программировании — то может стоит взять Head First Java?
LooksWorking
06.10.2017 00:15Как страшно учиться чему-то новому, ведь придётся же учиться чему-то новому.
Antelle
05.10.2017 23:11Скажи «нет», это что работало бы одинаково хорошо и в браузере и в десктопе. И чтоб бесплатно и без плагинов. А так не интересно. Жду, когда запилят framework на webassembly.
forth
05.10.2017 23:58Десять лет назад невозможно было себе представить, что стек веб-технологий можно использовать для создания десктопного приложения.
Встраиваемый IE активно используется в Десктоп-приложениях года эдак с 2000. Есть и такие, в которых используется «встроенный IE + встроенный веб-сервер + встроенный PHP».
asmrnv777
06.10.2017 01:56+1Я — мобильный разработчик, в основном Android. Пробовал JavaFX — это ад какой-то с точки зрения верстки. Вроде и там и там всё в XML похожим образом делается, но в JavaFX это делается как-то через задницу. Не могли что ли у андроида подсмотреть?
khim
06.10.2017 02:06+1Оно раньше Андроида появилось. Но тут есть важная разница: JavaFX создали архитектрные астронавты, которые сами на нём ничего особо не писали. А Андроиду — нужно было, прежде всего, заставить работать те приложения, что с системой поставляются. А уж потом — всё остальное.
Sap_ru
06.10.2017 03:23+2Все хорошо, но…
В fx нет нормального контрола для вывода rich text. Так, чтобы пользователь выделять мог, чтобы можно было динамически изменять, чтобы картинки были, чтобы нажатия определять. Или встроенный web со всем сопутствующим адом. Или чего-то не будет. И это катастрофа. Особенная катастрофа, если вначале казалось, что это приложению не нужно, а потом понадобилось.
Это очень серьёзный недостаток и причина, почему я с болью буду слезать с fx, имея уже готовое приложение.
Вторая проблема — fx нет и не будет на ARM. И это тоже катастрофа. Этот рынок сейчас растёт и потребность уже есть. Это потеря кросс-платформенности и вторая причина, почему мне придется отказаться от fx в пользу swt несмотря на потерю кучи времени.
И конечно же баги и архитектурные просчеты, которые висят десятилетиями. Попробуйте динамически менять псевдоклассы контролу. А без этого даже нормальной лейбы меняющей цвет фона нормальной не сделать. Есть ещё беда с таймерами и вызовом функций fx. Есть горе с динамическим определением и изменением размера окно (окно, которое имеет заданный размер клиентской области, например — простейшая вещь). Огромная проблема со сглаживанием шрифтов (попробуйте запустить приложение на Linux-системе с двумя мониторами) Это из простого, известного и первого пришедшего на ум. Казалось бы без этого можно жить, но в результате затраты на написание качественного GUI-приложения оказываются огромными, а некоторые простейшие, но заметные пользователю вещи просто невозможны.
В результате совершенно невозможно это использовать для серьезных долгоживущих проектов — только простейшие поделки. В то же время тот же swt позволяет все эти проблемы решить. Некоторые с болью и слезами, да. Но со временем это компенсируется наработками и окупается качеством пользовательского интерфейса и скоростью разработки последующих проектов.
Короче, после долгого времени активной разработки на fx (и даже массы восторгов на первых парах) пришло ужасное понимание, что несмотря на все наработки, в перспективе это тупик — риски велики, затраты тоже велики, результат проигрывает конкурентам.foatto
08.10.2017 13:14Ох, парни…
Информация из двух комментариев, Terras и вашего, меня повергает в уныние…
— «на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.»
и
— «fx нет и не будет на ARM»
Недавно перенёс десктопное приложение (таблицы, формочки, картография битмап+векторная, графики) с Java7+Swing на Java8+JavaFX, в связи с тем, что пришлось добавить поддержку воспроизведения видео и в перспективе маячили 3D-схемы пром.объектов.
Чуть было не завёл на iMX6+FrameBuffer на одной промплате, споткнулся/завис на шрифтах, пока отложил, нет опыта в сборке правильного линюкса под это дело.
Самое время переходить на Java9+SWT? Грусть. И х86 на девятку вроде как решили не завозить…
Других вариантов нет?
P.S. Qt не вариант по ценам и по тому, что есть порядочно общей кодовой базы между сервером/десктопом/андроидом.
P.P.S. JavaScript. Писал немного в молодости, с тех пор готов влезть в Kotlin/JS, лишь бы не в яваскрипт.
pmcode
06.10.2017 07:28+3Я писал несколько внутренних проектов на JavaFX, и в следующий раз буду писать на Electron, и вот почему:
— кроссплаформенность Electron выше. Например, у меня на Linux в WebView плавают цвета шрифтов.
— Electron позвляет использовать JS фреймфорки, а тот же Vue намного удобнее API JavaFX. В дополнение можно взять какой-нибудь ElementUI со стандартными компонентами.
— CSS в JavaFX — это такой очень специфичный CSS, писать и отлаживать который сущее мучение. Постоянно приходится луркать по стандартному modena.css и смотреть какие и где используются селекторы.
— платформа стагнирует, комьюнити не развивается и это очень заметно.
JavaFX в сравнении с Electron выигрывает только «бэкендом». Java позволяет использовать любые библиотеки, а вот с бинарными зависимостями в nodeJS придется попариться.
Senyaak
06.10.2017 07:45-5Как по мне Java во многом уступает JS языку изза большей развитости последнего. А сравнивать ооп язык и мультипарадигмальный язык вообще не стоит — последний будет всегда лучше для разработки.
poxvuibr
06.10.2017 07:58Как по мне Java во многом уступает JS языку
А во многом это в чём? Хотя бы 3-4 пункта. У JS вообще есть один существенный минус по сравнению с Java. Можно писать на каком-нибудь другом языке и компилировать его в jvm байт код. А вот в случае с джаваскриптом, если пишешь на другом языке — его можно скомпилировать только в джаваскрипт, со всеми вытекающими.
lair
06.10.2017 11:29Как по мне Java во многом уступает JS языку изза большей развитости последнего.
Примеры в студию.
Emacs232
06.10.2017 07:45-2> Пишем быстрое десктопное приложение на JavaFX
Это шутка такая? На жабе для десктопа разве только развесистые профессиональные приложения писать не требующие высокой производительности. А так все гуи-приложения что видел на любом жабовском фреймворке для десктопа ощутимо неспешны.
Не, конечно аполегеты утверждают иное, но в реальности я ещё ни разу не видел нормально работающее десктопнее жабо-приложение: медленно запускается, ощутимо медленно открываются окошки, ощутимо медленно происходит реакция на всякие нажатия и т.п.Pro-invader
06.10.2017 10:07Если не видели, то подскажу: Idea, Android Studio.
Free_ze
06.10.2017 11:10Идея не то, чтобы быстрая, но сносная.
khim
06.10.2017 12:53Запустил я как-то её на стареньком ноуте с 2 гигами памяти на HDD… Ага, конечно, сносная — если у вас ресурсов немеряно.
Как тут уже многие говорили: монстр Qt (реально монстр и тормоз если сравнить его с фреймворками XX века!) становится маленьким и юрким, когда его начинают сравнивать с Electron'ом и JavaFX…poxvuibr
06.10.2017 13:11Запустил я как-то её на стареньком ноуте с 2 гигами памяти на HDD… Ага, конечно, сносная — если у вас ресурсов немеряно.
А на какой девелоперской машине их сейчас мало?
khim
06.10.2017 16:59+2Не путайте тёплое с мягким, пожалуйста. Вопрос был: «бывают ли быстрые декстопные жабо-приложения». Ответ — нет, не быват, и Idea/Android Studio контрпримером не являются, оно тормозит безжалостно и не кажется ужасным кошмаром только за счёт того, что деволоперы работают на машинках за $5000, а не за $500.
Если же ваше приложение рассчитано на более широкую аудиторию, то этот подход — не очень годится: если это ваше основное приложение, которым вы деньги зарабатываете, то вы можете ему это простить и прикупить для него «лишние» 4-8-16GB памяти, но если это какой-нибудь проигрыватель музыки — то вы, скорее всего, предпочтёте что-нибудь другое…zirix
06.10.2017 18:05На старом ноуте с HDD тормозит все. В особенности «програмные монстры» типа браузеров и IDE.
Мне приходилось работать в Eclipse на старом ноуте с целероном, 2 гигами оперы и SSD. Было вполне конфортно и без ужасов, которые вы описываете.
Обычные приложения на java (не монстры) даже на слабом железе работают быстро.khim
06.10.2017 18:57На старом ноуте с HDD тормозит все.
Позвольте мне не поверить. Visual Studio 6 или какой-нибудь Delphi 2.0 там «летают».
В особенности «програмные монстры» типа браузеров и IDE.
В случае с браузерами всё в меньшей степени зависит от браузеров и в большей — от сайтов, которые вы посещаете. Какой-нибудь gcc.gnu.org или там lwn.net тоже нифига не тормозят несмотря на «жалкие» 1GB памяти и «несчастный» Atom, а вот банк-клиент на каком-нибудь «моднючем» фреймворке — тут да, без слёз не взглянешь.
Обычные приложения на java (не монстры) даже на слабом железе работают быстро.
Не заметил. Опять-таки: uTorrent на этом самом Атоме летает и систему не грузит, как Vuze запустишь — так она только им и занята. Даже если там не так много активности.
У Java-приложений много достоинств, но скорость работы и потребление ресурсов у них ужасны. То, что Electron побил все рекорды и теперь простенький редактор занимает не пару мегабайт в памяти, а пару гигабайт не означает, что Java вдруг стала менее жрущим монстром.zirix
06.10.2017 20:10Позвольте мне не поверить. 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), который не называет на каждом углу тормозным…khim
06.10.2017 21:04А запуск? 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), а современными — оно будет жрать пару гигов?
Что и где «пошло не так»?zirix
06.10.2017 23:02Больше наворотов в UI? Какие же?
У Vuze нестандартный интерфейс с мелкой анимацией и штуками типа Swarm view. Плюс p2p чат, плагины итп. Все это сказывается на потреблении CPU и оперативки.
Плюс невысокое качество кода (он жрет 2-3% ядра i7 2600MHz даже когда не качает) и мы получили тормоза на атоме.
Почему что-нибудь подобное сделать «с технологиями прошлого века»
Разработка нестандартного(не нативного) интерфейса (ака WinAmp) требует квалификации и времени.
На электроне намного легче и быстрее сделать такое приложение (Тяп-ляп и в продакшн). А дикое потребление оперативки и лаги — проблема пользователей, пускай купят новый ПК…
Если говорить про IDE:
Сейчас текстовые редакторы, типа Emacs, могут больше чем IDE прошлых веков.
Дополнительный функционал + экономиия человеко-часов разработчиков — это причина появления монстров, которые требуют дорогое железо.
С операцонными системами точно такая же ситуация.
Emacs232
07.10.2017 00:50-1Драсьте!
Я каждый день использую Gogland, чуть реже CLion.
Софт от Jet Brains это типичный образчик «развесистого профессионального приложения». Gogland, в принципе, работает сносно, т.к. Go сам довольно простенький. А вот CLion иногда еле-еле ворочается на не самых больших кусках.
zorn_v
06.10.2017 07:45Хорошая статья.
Долой хайп, пишем на брейнфаке.
Просто потому что мне нравится брейнфак, а не потому что хайп не зря.
k0st1x
06.10.2017 09:48есть ли приложение на JavaFX, которым можно гордиться?
Terras
06.10.2017 09:55Да, у нас NASA есть какая-то херня, которой можно траекторию спутников высчитывать и что-то еще делать. Они его написали на JavaFX, так как биг-дата толи на скале, толи на Java считались.
А так нет =)
jRonn
06.10.2017 11:48мне кажется хороший пример использования его :)
bitbucket.org/JavaSabr/jme3-spaceshift-editor
terminator-light
08.10.2017 16:42У меня Intellij IDEA запускается за 10 сек, а Visual Studio за 1 мин 20-30 сек (сами проекты не открываются). NetBeans за 30 сек. То время, когда написанное на Java быстрее, чем на c++
khim
08.10.2017 18:34У меня 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++-программами.terminator-light
08.10.2017 19:35VS 2015, windows 7, RAM 4GB, HDD. Проект с шаблоном asp.net mvc в нем слишком долго создается вплоть до минуты, даже в NetBeans до 15 сек занимает создание проекта с шаблоном web.
khim
08.10.2017 20:34Ну дык эта: архитектурная астронавтика и C#, чего вы хотите? Как я уже сказал: Visual Studio на C++ — это история. Это из LibreOffice выпиливают Java'у (и последние версии пошустрее работают), в Visual Studio — наоборот…
Tallefer
09.10.2017 01:00Серьезно, выпиливают? А на что заменят и есть ли навскидку ссылка почитать про эти планы?
khim
09.10.2017 13:30Вот прямо у них на страничке Development/Java. Она, собственно, с этого тезиса начинается. А закачивается разделом «Suggestion to Remove Java Components».
На что меняют? На то, что и было: C/C++. Но Sun успел изрядно засрать кодовую базу компонентами на Java, работы много.
Crandel
09.10.2017 14:48+1Статья была создана в 2012 году, все проверки проводились с кодом версии 4.2.6.3(28-Aug-2014 03:09) Скачал последние исходники и сделал первую проверку — отсутствует только одна директория accessibility/ так что про полное выпиливание пока речи не идет
Tallefer
09.10.2017 01:16Кстати, поздно вспомнилось, но раз тема про электрон, то грех было бы не упомянуть: есть такая фришная игра Duelist, карточно-тайловые бои, пиксельная (на мой вкус — слегка чересчур) анимация фигур и очень красивые арты, но речь не про качество игры как таковой.
В версиях до релиза (сейчас не проверял), игра скачивалась в двух частях — сначала лаунчер, а потом в нем авторизация и докачка основного тела игры, ну в общем все как обычно.
Суть прикола — лаунчер сделан на электроне, но закачивает он игру, которая тоже на электроне, даже файлы те же самые! Но при этом игра занимает МЕНЬШЕ лаунчера, КАРЛ! %) Примерная пропорция — где-то 150 метров на лаунчер и 120 на игру. :D
Единственное объяснение (если оно кого-то заинтересует) — в лаунчере замастрячили интро-видос в фуллхд и много анимированного графона на задник и кнопки.
awMinor
Мне кажется, что для корректного сравнения все же стоило добавить так же часть разработки точно такого же приложения на Electron. И в конце все же их стоит сравнить, а так же сравнить при возможности скорость разработки такого приложения.
igorp1024
Как мне кажется, следует различать ситуацию, когда пишется приложение для АРМ заказчика (автоматизированное рабочее место) и когда у пользователя на десктопе зоопарк electron-приложений.
Если рассматривать первый случай — Вы совершенно правы, и сравнить скорость разработки на разных платформах смысл есть, и выводы могут быть в сделаны в пользу платформы electron.
Но если рассматривать второй случай… У меня, в частности, сейчас запущены skype for linux, slack и atom. И честно говоря, я как обычный пользователь, предпочёл бы иметь их в виде чего-то более шустрого/нативного и с более умеренными аппетитами. И был бы против прироста поголовья постоянно запущенных electron-приложений у себя на десктопе.
p.s. Хотя, справедливости ради, к официальному slack-клиенту претензий намного меньше, чем к альтернативному scudloud и особенно к skype for linux.
lieff
У слака это возможно зависит от количества каналов и истории. У меня слак выжирает до 2.5гб. Я писал им в поддержку, они согласились, что это bad experience, но сделать ничего так и не сделали.