Comments 73
а как насчет вместо электрона юзать WebView из javafx?
Оно старое и медленное, там есть проблемы с CSS3 анимациями. И там совсем другие баги, а Electron — это свежий Chromium, что радует.
оно обновляется потихоньку, баги фиксятся. У вас довольно простой ui, судя по скриншотам, проблем быть не должно. Не нужно тащить лишние зависимости, возможно памяти будет жрать меньше
Не кросс платформенно. Не работает на ARM.
а электрон работает?
А за электрон вообще стрелять нужно. Если только это не что-то жирное и корпоративное. Работать-то он работает (более менее), но жрёт столько…
Скачал посмотрел я CUBA Studio. При запуске установки вылетела. Второй раз установилась, но не запускается, вообще. Windows 10 x64, SSD, 16 gb RAM. Как-то упало сразу настроение… буду разбираться.
Вот это не классно, у вас случаем не JDK 9/10? Если что, заглядывайте к нам на форум: www.cuba-platform.ru/discuss Нам тоже хотелось бы понять в чём дело
jdk1.8.0_162 процессы просто висят в памяти
Насколько я помню Oracle, сама рекомендует для desktop приложений тащить свою jre, есть даже ужатые варианты.
При старте браузер-edition получаю такое сообщение
Похоже что, что-то недоустановилось капитально, у вас всё в порядке с JDK на компьютере? Мы пока не поддерживаем запуск на JDK 9. Если вы её устанавливали, то она могла остаться дефолтной JRE.
Скажите, а есть готовые бизнесс-приложения, которые можно посмотреть?
На этом стеке (Electron.js + Java) мы пока делаем только Studio, около полугода как выпустили. Бизнес приложения тоже на подходе.
Приложения на платформе можно найти здесь: www.cuba-platform.com/case-studies
Приложения на платформе можно найти здесь: www.cuba-platform.com/case-studies
В данный момент CUBA Studio не поддерживает Java 9 и Java 10, надо ставить Java 8. У меня была ровно такая же проблема.
Ссылка на вопрос в техподдержку
Ссылка на вопрос в техподдержку
Печально все это, 4 относительно несложных(имеется в виду предоставляемая функциональность) приложения, например хром, слэк, скайп и например ваша программа запросто проглотят 8 гб(далеко не у каждого лэптопа хочу заметить!) оперативы и система превращается в слайдшоу либо агрессивно изнашивает ссд используя как своп.
А чем так плох вариант создания локального сервиса с веб интерфейсом? Ну кроме цены разработки. Двойным кликом запустил — открылся браузер и сервис для передачи данных в браузер, тут сразу все модные штуки в UI будут и доступ к локальной машине полноценный как у обычного приложения
Будем надеяться, что AvaloniaUI сможет составить достойную конкуренцию вот этому всему.
Ну так это опять надо изучать XAML, знания HTML/CSS там не получиться применить
Между AvaloniaUI и JavaFX принципиальной разницы нет: и там и там — специализированный язык разметки формы, немного CSS, и этого, в принципе, должно хватить на формы для офисной системы.
А это гуано (Java + Electron) надо выкидывать сразу же.
А это гуано (Java + Electron) надо выкидывать сразу же.
А тем временем ребята из JetBrains не комплексуют и пилят свою Idea на swing :)
1. Это огромный продукт, который не надо сильно кастомизировать каждый релиз. 2. У них много квалифицированных кадров, которые могут продолжать писать на Swing.
а разве большинство десктопных продуктов надо «сильно кастомизировать» каждый релиз?
уж поверьте, для написания свинг приложений не требуются какие-то особенные квалифицированные кадры, достаточно обычных людей с руками из плеч.
уж поверьте, для написания свинг приложений не требуются какие-то особенные квалифицированные кадры, достаточно обычных людей с руками из плеч.
А вы спросите этих людей с руками, нравится им писать на Swing? Захотят они новый проект писать на нём? Смогут они новые требования заказчиков на нём выполнить?
А веб разработчикам не только нравится, они и сделают быстрее и качественнее.
А веб разработчикам не только нравится, они и сделают быстрее и качественнее.
UFO just landed and posted this here
Веб-разработчик, десктоп и качественнее? Фантастика на втором этаже. Никогда не любил десктоп на яве. Но десктоп на электроне — это уже из серии «и тут снизу постучали». Он объединяет недостатки как веба (никакущая виртуализация, огромное потребление ресурсов, тормоза), так и классики (необходимости установки, зависимость от окружения, безопасность).
Ну да. А про плагины, которые пишут совершенно отдельные люди, вы видимо забыли?
А эклипс, который судя по комментариям, тут кое-кому не нравится — вы никогда не видели, как именно его можно кастомизировать? Какой-нибудь dbeaver, для примера?
На мой взгляд, все что тут понаписано, вполне себе имеет право на жизнь, вот только не надо при этом бездоказательно критиковать родные для Java технологии. Прежде чем это делать, нужно все-таки показать что-то, близкое к эклипсу/идее по масштабам и расширяемости.
Ну т.е., при всех их реальных недостатках, на swing и на javaFX реально пишутся и широко используются вполне себе хорошие продукты. Если при этом взять тот же котлин, или груви, то это получается еще и достаточно просто. И честно говоря, то что при этом у JavaFX немного недо-CSS, всех использующих реально волнует в последнюю очередь.
А эклипс, который судя по комментариям, тут кое-кому не нравится — вы никогда не видели, как именно его можно кастомизировать? Какой-нибудь dbeaver, для примера?
На мой взгляд, все что тут понаписано, вполне себе имеет право на жизнь, вот только не надо при этом бездоказательно критиковать родные для Java технологии. Прежде чем это делать, нужно все-таки показать что-то, близкое к эклипсу/идее по масштабам и расширяемости.
Ну т.е., при всех их реальных недостатках, на swing и на javaFX реально пишутся и широко используются вполне себе хорошие продукты. Если при этом взять тот же котлин, или груви, то это получается еще и достаточно просто. И честно говоря, то что при этом у JavaFX немного недо-CSS, всех использующих реально волнует в последнюю очередь.
UFO just landed and posted this here
Да, надо определённо попробовать для варианта без сети, правда там пока только Java 8 поддерживается. И есть риск что javah удалят скоро из JDK: openjdk.java.net/jeps/313 что сломает этот модуль
Складывается ощущение, что статью писал нездоровый человек, незнакомый с реалиями компаний. Цитирую:
И
В компаниях намертво фиксируется окружение для приложения: для IBM/Lotus Notes автоматически устанавливается приватная JRE от IBM, для SAP R/3 ставится JRE от SAP, для 1С Торговли, которая надёжно работает только под 1С 7.7.25 ставится именно эта платформа и так далее. Нет никакой проблемы в том, чтобы запустить даже старинное приложение на AWT, не говоря уж о SWING, в современном enterprise.
Чаще всего дополнительное оборудование используется в enterprise приложениях: банках, ERP, бухучете и т.д.
И
Кроме того, есть задачи, которые плохо могут быть решены в web. Главная из них — независимость от серверов и сети.
В компаниях намертво фиксируется окружение для приложения: для IBM/Lotus Notes автоматически устанавливается приватная JRE от IBM, для SAP R/3 ставится JRE от SAP, для 1С Торговли, которая надёжно работает только под 1С 7.7.25 ставится именно эта платформа и так далее. Нет никакой проблемы в том, чтобы запустить даже старинное приложение на AWT, не говоря уж о SWING, в современном enterprise.
Говоря о независимости от серверов, я имел в виду оффлайн в веб-приложениях, а не софт серверов. В цитате речь идёт об этом.
Эмм, я очень непродуманный комментарий написал.
В статье описываются проблемы:
Так вот, я хотел сказать, что проблем с GUI, на самом деле, нет, так как в тех компаниях, где я работал, на всех клиентских и серверных компьютерах ПО ставилось скриптами, и для каждого приложения была жёстко зафиксирована платформа: для клиента Lotus Notes — приватная JRE от IBM, для клиентской части SAP — JRE от SAP, а для каких-то своих приложений (наподобие JPassword safe, SQuirreL SQL client, и, собственноб Ecipse — JRE от Oracle.
Просто перед развёртыванием ПО у клиента надо прописать нужную версию JRE в требованиях к среде выполнения вашего ПО.
В статье описываются проблемы:
- сложно сделать GUI, так как SWING, JavaFX не развиваются.
- Нет возможности поставить на клиента нужную версию JRE.
Так вот, я хотел сказать, что проблем с GUI, на самом деле, нет, так как в тех компаниях, где я работал, на всех клиентских и серверных компьютерах ПО ставилось скриптами, и для каждого приложения была жёстко зафиксирована платформа: для клиента Lotus Notes — приватная JRE от IBM, для клиентской части SAP — JRE от SAP, а для каких-то своих приложений (наподобие JPassword safe, SQuirreL SQL client, и, собственноб Ecipse — JRE от Oracle.
Просто перед развёртыванием ПО у клиента надо прописать нужную версию JRE в требованиях к среде выполнения вашего ПО.
И ещё минусы: при использовании Электрона наше приложение зависит от трёх компонентов: Chromium, node.js и JVM. А в нормальном Java-приложении мы зависим только от JVM. Для чего всё и делалось изначально. Вдобавок к этому, мы получаем замечательную попоболь в организации совместной работы Электрона и нашего мини-вебсервера на Джаве. И памяти всё это будет жрать, как не в себя: пара гигов — браузеру, пара гигов — ноде, и всё, что осталось — джаве. Тупиковый путь. Не берите, люди, эту каку в руки!
> И памяти всё это будет жрать, как не в себя: пара гигов — браузеру, пара гигов — ноде, и всё, что осталось — джаве
Это вы совсем мимо. В нашем приложении весь Electron (вместе с Node.js) потребляет 100 MB памяти. Это не браузер, в котором юзер себе открывает сотни вкладок. Это движок рендеринга страниц, который управляется разработчиком.
Это вы совсем мимо. В нашем приложении весь Electron (вместе с Node.js) потребляет 100 MB памяти. Это не браузер, в котором юзер себе открывает сотни вкладок. Это движок рендеринга страниц, который управляется разработчиком.
А что не так JavaFx? Что CSS не вебовский или еще причины есть? Приложения получаются на пару мегабайт, жирнеют лишь от добавляемых либ, а Scene Builder помогает быстро вьюхи клепать…
UFO just landed and posted this here
Electron, это, конечно, замечательно.
Но почему в нем мессенджер жрет ресурсов, как Idea с открытым проектом?
Но почему в нем мессенджер жрет ресурсов, как Idea с открытым проектом?
Ага, давайте интерфейсы на html писать. Сумасшедшая идея.
На 95% бред, а не статья.
На 95% бред, а не статья.
UFO just landed and posted this here
на мой взгляд.
на данный момент, немного слабовато сделаны некоторые компоненты(притом по мелочам).
а так всё очень достойно.
btw: а разве вид «как на электроне» — это хорошо?
цель, как правило, непугать юзера нестандартным внешним видом, а выглядить как остальной гуй.
на данный момент, немного слабовато сделаны некоторые компоненты(притом по мелочам).
а так всё очень достойно.
btw: а разве вид «как на электроне» — это хорошо?
цель, как правило, непугать юзера нестандартным внешним видом, а выглядить как остальной гуй.
Он сыр, крив, не портируем и ужасен. Покажите мне вменяемый Richedit на Fx.
вот richtext editor одна из компонент мною никогда неиспользуемых, да и вобще редкая задача :)
есть вроде — HTMLEditor, StyledTextArea, RichTextFX, TextFlow умеет картинки всякие и прочее, ну и WebView никто не мешает заюзать
есть вроде — HTMLEditor, StyledTextArea, RichTextFX, TextFlow умеет картинки всякие и прочее, ну и WebView никто не мешает заюзать
WebView
Будто в вебе есть нормальный RTE.
Редка задача вывести заранее неизвестный текст разными шрифтами? Задача типовее некуда. Журналы, протоколы, статусы системы — да в любом приложении. Начиная со сраного мессенджера. Написать сраный мессенджер на JavaFX это неисполнимый квест, кстати.
Ну, вы в курсе, что StyledTextArea/TextFlow не позволяет пользователю скопировать текст в буфер обмена? Кому оно такое нужно?
HTMLEditor убог для таких целей.
WebView? Шутите? Тащить за собой полноценный Web-движок ради 10 строк текста? Иметь на форме 5 WebView одновременно?
И при всё при этом он плохо подходит — сложно контролировать, сложно управлять прокрутками и т.п.
Вот потому десктопные программы на Java и ненавидят.
Ну, вы в курсе, что StyledTextArea/TextFlow не позволяет пользователю скопировать текст в буфер обмена? Кому оно такое нужно?
HTMLEditor убог для таких целей.
WebView? Шутите? Тащить за собой полноценный Web-движок ради 10 строк текста? Иметь на форме 5 WebView одновременно?
И при всё при этом он плохо подходит — сложно контролировать, сложно управлять прокрутками и т.п.
Вот потому десктопные программы на Java и ненавидят.
Не совсем понятен мотив использования электрона. У вас уже есть одна зависимость в системе — JVM, и наличие зависимости от браузера уже не принципиально. Сделайте Jetty + Vaadin и открывайте при запуске страницу в system default browser. Ваш электрон в минималке займет лишние 100Mb. Если попытаетесь заэмбеддить jre, то это еще плюсом 180мб, а если все скомпилируете AOT, то будет около 250мб. Итого 350мб для простого "хелло ворлд", что может быть и оправдано для девтулзы, но для простого нативного клиента — вряд ли.
Далее, так ли принципиальна зависимость от джавы? Для клиентских технологий есть куча приблуд для джавы: JSweet, GWT, TeaVM, вплоть до полной JVM на JS: CheerpJ.
Ну и по способу деплоймента: зачем бандлить электрон и установщик и почему бы не сделать Chrome Application, распространяемую через Chrome Store?
Уже много лет делаю десктоп приложения на SWT. Родной системный интерфейс, все компоненты ведут себя как надо, работает очень быстро, памяти жрет мало, баги фиксятся(более того, даже исправлены некоторые баги в отрисовке компонентов которые есть в windows/linux/etc). Если надо что-то нестандартное, то нужно писать самому, но это не страшно, если руки из нужного места.
А статье указано что SWT не развивается, а как он должен развиваться? Это прослойка для вызова нативных UI функций операционной системы. Если что то появляется в ос, то соответственно появляется в библиотеке. Никто не обещал что будет 100500 компонентов для рисования супер модного UI как в вебе.
А статье указано что SWT не развивается, а как он должен развиваться? Это прослойка для вызова нативных UI функций операционной системы. Если что то появляется в ос, то соответственно появляется в библиотеке. Никто не обещал что будет 100500 компонентов для рисования супер модного UI как в вебе.
После строки про компиляцию Java в JS моментально расхотелось читать(
Sign up to leave a comment.
Блеск и нищета Java для настольных систем