Комментарии 185
Как мне кажется, следует различать ситуацию, когда пишется приложение для АРМ заказчика (автоматизированное рабочее место) и когда у пользователя на десктопе зоопарк electron-приложений.
Если рассматривать первый случай — Вы совершенно правы, и сравнить скорость разработки на разных платформах смысл есть, и выводы могут быть в сделаны в пользу платформы electron.
Но если рассматривать второй случай… У меня, в частности, сейчас запущены skype for linux, slack и atom. И честно говоря, я как обычный пользователь, предпочёл бы иметь их в виде чего-то более шустрого/нативного и с более умеренными аппетитами. И был бы против прироста поголовья постоянно запущенных electron-приложений у себя на десктопе.
p.s. Хотя, справедливости ради, к официальному slack-клиенту претензий намного меньше, чем к альтернативному scudloud и особенно к skype for linux.
А как пользователь, я эти вечно запинающиеся полувеб-приложения, и тех, кто их пишет, ненавижу. И себя тоже :)
Хотя веб, конечно, тот еще бардак, у него есть два огромных преимущества:
- веб много лет эволюционировал для разработки UI. В результате в нем есть классные подходы типа FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке (кроме React Native).
- компонуемость: практически нет ограничений на содержимое элемента, поэтому можно довольно легко делать очень сложные вещи, типа тех же гридов.
Как на Java FX сделать сложный грид? Как вывести туда данные? Можно ли сделать меню у заголовков столбцов?
Единственный, на мой взгляд, реальный конкурент веб-подходам на десктопе — это мобильные приложения, но им еще долго догонять веб-приложения по удобству разработки.
Единственный, на мой взгляд, реальный конкурент веб-подходам на десктопе — это мобильные приложения
«Земля тряслась — как наши груди, Смешались в кучу кони, люди, И залпы тысячи орудий.»
В результате в нем есть классные подходы типа FRP
Qt включает в себя язык QML который поддерживает биндинги.
Как я понимаю это то FRP о котором вы говорите.
FRP, которых нет (насколько я знаю) ни в одном десктопном фреймворке
FRP на десктопе уже давно.
Например, ReactiveUI появился ещё в 2010 году и, думаю, он был далеко не первым.
Вы, конечно же, шутите? Даже в предшественниках — AWT, Swing и если немного в сторону, у SWT, все это было в полный рост, цвело и пахло (как и у любой достаточно продвинутой GUI системы), когда веб пешком под стол еще ходил. Более того, все это делается гораздо проще.
Судя по тому, что я видел на javafx, если говорить о ресурсоемкости приложений, это один из тех случаев, когда ДАЖЕ электрон лучше.
Ну а популярнее станет тот, в котором быстрее кодить и который прощает больше говнокода)
Что мы имеем спустя годы? Примерно тоже самое, тоже лагающее, такую же нехватку ресурсов и прочее, просто незаметно для нас, в фоне, выросли скорость и объём, и тут же были нещадно облюбованы поделками, разработанными неквалифицированными
Лично для меня, как для разработчика, а также пользователя, — опыт использования electron-приложений показал что динамические ЯП — моветон, и наивное расточительство, а electron — есть апогей этого порока, убедительная крайность. Electron-приложения я больше не использую, nuff said.
К счастью сейчас есть ряд инструментов позволяющих разрабатывать эффективно, абстрактно и высокоуровнево, при этом сводя к минимуму последствия этих удобств, без всяких виртуальных машин, иногда даже без GC. И как бы между прочим, JVM и этот JavaFX не входят в этот список благодетелей.
А чем проверенная связка HTML+CSS+JS вам не угодила понять не могу, возможно, только отсутствием визуального редактора.
А чем проверенная связка HTML+CSS+JS вам не угодила понять не могу
А вы точно работали с VCL? А то я каждый раз при разработке веб-чего-нибудь ловлю себя на мысли, что пишу руками кучу кода, который 20 лет назад я набрасывал мышкой за полчаса.
но вот в какой-то более менеее сложный UI
Что такое «более-менее сложный UI»? Десктопные приложения «в среднем» всегда имели в разы более сложный UI, чем современные веб-приложения.
а уж, упаси боже, анимации на нем раз в 5 сложнее реализовываются.
Минуточку, мы говорим про библиотеку, которой почти четверть века. В эпоху VCL потребность в анимации UI отсутствовала как класс. Сейчас ну да, хотя возможно за эти годы уже какую-то библиотеку анимации/трансформации наверняка кто-то написал, если этот вопрос вообще был востребован.
Думаю электрон начал набирать обороты из-за того что увеличились свободные ресурсы в трафике и производительности.я когда вижу, как скайп на моем ноуте под линухом отъедает 3 Гб и 100% процессора, так и хочется увидеть этих программистов и высказать им все, что я о них думаю. Помогает только перезапуск скайпа.
Он говорит, что изначально проект вообще хотели закрыть, но потом передумали и просто «заморозили его».
Я к тому, что нефиг выпендриваться. Java — это веб-морда, хочешь писать десктоп (натив, глючные электроны или тяжеловесный QT)
тяжеловесный QT
Когда рядом в предложении стоит электрон и Java, Qt становится маленьким и юрким.
но на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.
пруф линк?
Думаю, таких статей можно написать по числу языков программирования. Каждый пишет на том, что знает. Никто не будет изучать Java и JavaFX/C# и WPF/Лелика и Болика только чтоб написать одноразовый просмотрщик логов с полутора юзерами, все сделают на том, что знают.
или я что-то перепутал?
Перспективную эту штуку щас добивают в мозилле:)
Я не помню, чтобы у кого-то баттхертило (наверное потому что я тогда еще не ходил linux.org.ru) от XUL.
Да софта на нем было было не в пример меньше.
github.com/FibreFoX/javafx-gradle-plugin
www.youtube.com/watch?v=7n41K2GT9YY
Пробовал компилировать для Windows и Linux — успешно.
Все красивости делаются с помощью CSS
Справедливости ради, это никакое не "нативное" приложение, а только обёртка для вызова утилиты javapackager
из JDK, которая упаковывает приложение и JVM в один exe-файл. Хотя для пользователя разница невелика.
JDK 9 в теории может повыбрасывать оттуда все неиспользуемое и футпринт будет уже совсем не в пользу Electron. На практике я это пока не пробовал.
- стили это очень удобно — можно просто и быстро менять внешний вид, иконки и прочее
- fxml — очень крутая штука, как и в qt — qml. Можно отдать на откуп дизайнеру и всё,
сосредоточиться на коде - куча готовых примеров на все случаи жизни
- нет встроенных компонентов для диалогов и визардов, помогает controlsFX
- на всех платформах где есть java 8 будет выглядеть одинаково — win32\64 lin32\64, да даже на raspberry pi
- глюки в самом нужном компоненте — в таблице
- если надо писать gui для desktop java — то лучше не найти, swing — уныл, swt — задобает количеством сборок для всех платформ
Ээээ… на всех платформах? Ну, вы же в курсе, что для ARM fx нет и не будет?
Если будет минутка, подробнее можно прочитать в блоге bell-sw.com/blog
Имею 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 не вызывает.
А это причина, по которой OSS лицензия не подходила.
A commercial license keeps your code proprietary
Available under GPL & LGPLv3 licenses
info.qt.io/download-qt-for-application-development
Да, вы правы, это был очень слабый аргумент. Или неверный.
Вообще, Qt меня очень привлекает с точки зрения ТТХ. Но как-то каждый раз с ним не срастается, слишком много нужно про него узнать.
Делаю хобби-проект с BLE 4.0. Тоже нужна небольшая программка, сидящяя в трее. С BLE 4.0 в Java довольно печально. Qt традиционно «не осилил», хотя честно пытался) А вот для node.js библиотека завелась с полтычка: github.com/sandeepmistry/noble. Если учесть, что мне еще нужны веб-сокеты для интеграции с внешним сервисом, а каких-то ограничений по размеру/производительности не стоит — выбор Electron выглядит вполне разумно.
Смущает следующее: «All you need is a BLED112 dongle on a PC.». Это реализация API для конкретного адаптера?
Когда пытаешься все это перенести на машину обычного пользователя, получается какой-то ад, и практически 100% что-то будет отваливаться, тупить и приносить «радость», не говоря уже про обновления.
А что у вас с оперативкой? И какая ОС (точнее важнее вопрос — отключён ли своп к ...)?
Своп не отключен, я часто выхожу за имеющиеся 16 Гб.Гроб. С музыкой. Докупить памяти и не мучаться.
К огромному сожалению Linux очень плохо работает со свопом. Потому что просто исторически считалось, что раз система ушла в своп — то всё уже и так очень плохо и можно «расслабиться». Появление SSD заставило людей задуматься об этом проблеме, но когда своп в Linux будет работать хотя бы сравнимо с тем, что в *BSD — науке неведомо.
Хм… Нет, даже в винде, где своп вылизали как могли >10% оперативки в свопе замедляют работу. >50% делают её паталогически неспешной с подвисанием UI.
В линуксе своп не нужен от слова совсем, но менеджить доступный объём приходится руками — это да, непривычно. Впрочем я и на винде при наличии возможности отключаю своп.
Дело в том, что ни в Windows, ни в Linux вы не сможете отключить своп «по настоящему». Потому что странички, принадлежащие программе всегда могут «уйти в своп» (их можно выкинуть из памяти, так как всегда есть возможность загрузить их из оригинального файла). То есть если у вас начинает кончаться память при наличии свопа — система замедляется, если то же самое происходит при его отсутствии — она замедляется катастрофически.
В Android'е эту проблему решили «ручным» OOM-киллером: процессы убиваются до того, как система «встанет колом». Но на десктопе соотвествующего watchdog'а нет, потому своп должен быть…
>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) могут вытеснить страницы, занимаемые кодом, даже при отсутствии своп файла\раздела.
Процессом чтения-с-диска/записи-на-диск вестимо. Или у вас только ssd уже?
Запись-на-диск — сброс свопируемых страниц. Чтение-с-диска — загрузка данных с диска (генерация данных прям в памяти — явление всё же редкое) и/или восстановление свопнутых страниц.
Если всё это происходит на классическом диске — это не очень быстро.
Если у меня приложениям (в сумме, вместе с системой) надо 10-12Гб оперативки, а у меня её только 8 — начинаются пляски. Расклад:
Ide ~2Гб
Браузеры (chrome + FF) — по 1Гб (минимум)
система + прочие приложения (по ощущениям — не меньше 1Гб, но больше похоже на 2)
и компиляция проекта GWT — 3-5Гб.
Если перед компиляцией выгрузить что-то одно ресурсоёмкое — система лишь немного подтормаживает после компиляции (и полностью тормоза лечатся — только перезагрузкой компа).
Если запускать прям-так, то компиляция происходит в ~2 раза дольше (9-15 минут) и после компиляции весь UI стоит колом (каждое переключение между вкладками браузера, каждое переключение между окнами приложений — тормоза. В течении получаса само не проходит, дольше не вытерпел — перезагрузил систему).
В общем у меня богатый негативный опыт работы со свопом и при отсутствии потребности я предпочту его отключить.
Сижу и кодю на "серверном" языке под Android...
Ну много ест памяти, требует зачастую JRE если не собрано с ним, тормозит и очень долго стартует если комп не самый быстрый и без SSD, ну и самое важное для меня чудовищно ест батарею на ноутбуке. Ушёл кстати от продукта JetBrains PyCharm на VS Code и не жалею.
Пункт подрыва завершен, а теперь конкретнее:
- У 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 очень прожорливая, так что если потребление ресурсов не является ключевым, то эта «технология» подойдет. Но выражения автора статьи меня подвергли к написанию такого вот объемного текста, не люблю когда кто-то преподносить технологию как панацею, это не профессионально просто.
Слишком широкое заявление. По сравнению с чем? На каких задачах? При каких настройках/ограничениях? У меня rails worker'ы больше памяти потребляют, чем куда-более нагруженный java сервис. Но выводов каких-то я из этого не делаю. Задачи разные и решены по разному.
Тем, что под него нет десктопного UI? AvaloniaUI пока в ясельном возрасте.
iOS, Android, Windows, Mac OS, Linux, даже никому не нужные Windows Phone и Tizen.
Я не удивлюсь если в течении полугода они принесут Forms в браузеры через WebAssembly (a.k.a реинкарнация SilverLight)
Стоп, но что из перечисленного относится к теме кросплатформенных десктопных приложений? (статья про них)
У меня это заняло два месяца этим летом.
Главным же недостатком Electrone является его прожорливость и большой вес даже минимального приложения. Я вижу такой путь к решению проблемы: завозим Electron в качестве VM, а exe-шник приложения по сути его запускает и скармливает нужные данные. И получаем сразу -90% от общего веса приложения (даже если от проблем с ОЗУ это спасет не особо, то компактность увеличит значительно), а о проблеме с ОЗУ надо уже отдельно думать.
Хм… Так это… Та же Idea умеет какие-то функции выбрасывать в локальный браузер… в чём тогда проблема вместо запуска толстого клиента вообще поднять локальный сервер, который будет работать с браузером?.. вряд ли это будет дороже, чем Electron...
Если уж кому-то совсем в край извратиться тот же сервер можно для управления обернуть Electron-ом(но это надо уж совсем извращенцем быть)
А такие решения уже есть. есть такая штука как cuba platform, так у них IDE это веб приложение поднимаемое на localhost'е.
Про легкость создания и настройки UI говорить не стоит.
Легкость для кого? Весь ужас и ад инструментов современного веба приходит на десктопы?
Так много слов чтобы сделать простейшие действия. Сразу столько концепций, объектов, функций. Пипец…
Десять лет назад невозможно было себе представить, что стек веб-технологий можно использовать для создания десктопного приложения.
Встраиваемый IE активно используется в Десктоп-приложениях года эдак с 2000. Есть и такие, в которых используется «встроенный IE + встроенный веб-сервер + встроенный PHP».
Все хорошо, но…
В fx нет нормального контрола для вывода rich text. Так, чтобы пользователь выделять мог, чтобы можно было динамически изменять, чтобы картинки были, чтобы нажатия определять. Или встроенный web со всем сопутствующим адом. Или чего-то не будет. И это катастрофа. Особенная катастрофа, если вначале казалось, что это приложению не нужно, а потом понадобилось.
Это очень серьёзный недостаток и причина, почему я с болью буду слезать с fx, имея уже готовое приложение.
Вторая проблема — fx нет и не будет на ARM. И это тоже катастрофа. Этот рынок сейчас растёт и потребность уже есть. Это потеря кросс-платформенности и вторая причина, почему мне придется отказаться от fx в пользу swt несмотря на потерю кучи времени.
И конечно же баги и архитектурные просчеты, которые висят десятилетиями. Попробуйте динамически менять псевдоклассы контролу. А без этого даже нормальной лейбы меняющей цвет фона нормальной не сделать. Есть ещё беда с таймерами и вызовом функций fx. Есть горе с динамическим определением и изменением размера окно (окно, которое имеет заданный размер клиентской области, например — простейшая вещь). Огромная проблема со сглаживанием шрифтов (попробуйте запустить приложение на Linux-системе с двумя мониторами) Это из простого, известного и первого пришедшего на ум. Казалось бы без этого можно жить, но в результате затраты на написание качественного GUI-приложения оказываются огромными, а некоторые простейшие, но заметные пользователю вещи просто невозможны.
В результате совершенно невозможно это использовать для серьезных долгоживущих проектов — только простейшие поделки. В то же время тот же swt позволяет все эти проблемы решить. Некоторые с болью и слезами, да. Но со временем это компенсируется наработками и окупается качеством пользовательского интерфейса и скоростью разработки последующих проектов.
Короче, после долгого времени активной разработки на fx (и даже массы восторгов на первых парах) пришло ужасное понимание, что несмотря на все наработки, в перспективе это тупик — риски велики, затраты тоже велики, результат проигрывает конкурентам.
Информация из двух комментариев, Terras и вашего, меня повергает в уныние…
— «на реддите было сообщение от JavaFX CORE разработчика, где он сообщил, что Оракл разогнал всю команду и оставил маленькую группу исключительно для фикса багов в том, что уже есть.»
и
— «fx нет и не будет на ARM»
Недавно перенёс десктопное приложение (таблицы, формочки, картография битмап+векторная, графики) с Java7+Swing на Java8+JavaFX, в связи с тем, что пришлось добавить поддержку воспроизведения видео и в перспективе маячили 3D-схемы пром.объектов.
Чуть было не завёл на iMX6+FrameBuffer на одной промплате, споткнулся/завис на шрифтах, пока отложил, нет опыта в сборке правильного линюкса под это дело.
Самое время переходить на Java9+SWT? Грусть. И х86 на девятку вроде как решили не завозить…
Других вариантов нет?
P.S. Qt не вариант по ценам и по тому, что есть порядочно общей кодовой базы между сервером/десктопом/андроидом.
P.P.S. JavaScript. Писал немного в молодости, с тех пор готов влезть в Kotlin/JS, лишь бы не в яваскрипт.
JS из молодости и современный ES6+, к счастью, довольно разные вещи.
SWT тоже не сразу там заводится, но там хотя бы принципиальный препятствий нет и есть хоть какие-то работающие готовые решения.
JS на embedded ARM?! При одном гиге ОЗУ, например? Очень странное решение. Это возможно. И даже работать будет, но нужно будет решать массу проблем по работе с ситемными ресурсами.
Пока, да, для ARM хорошо работает только C++/Qt и JS с некоторыми оговорками. Есть случае стабильной работы Java+SWT, но уже сложнее. Всё остальное не портабильно, в общем случае.
Вот тоже расстраивают скудные возможности работы с просто текстом. Там есть что-то, но закинуто в пакеты com.sun.javafx.*
, что означает, что в Java 9 придётся прописывать дополнительные разрешения для модулей, да и документации почти никакой.
И рендеринг шрифтов слабоват даже под Windows — раздражающая муть, так как субпиксельное сглаживание работает не пойми как. Но такая муть сейчас стала везде — и в Chrome, и в новом Firefox. Но это из-за того что GDI не используется, а D3D и прочее "аппаратное ускорение". Что удивляет, что народ эти мутные шрифты повсеместно терпит и даже вроде как не замечает.
Зато вот сборка OpenJDK от JetBrains под Windows использует нативный рендер и сглаживание, что вкупе с программой MacType даёт тексту отличное качество.
Swing выглядит гораздо гибче, и готовых наработок по нему больше. Но в целом, если устраивает интерфейс из полностью готовых элементов, то JavaFx справится.
Как по мне Java во многом уступает JS языку
А во многом это в чём? Хотя бы 3-4 пункта. У JS вообще есть один существенный минус по сравнению с Java. Можно писать на каком-нибудь другом языке и компилировать его в jvm байт код. А вот в случае с джаваскриптом, если пишешь на другом языке — его можно скомпилировать только в джаваскрипт, со всеми вытекающими.
Как по мне Java во многом уступает JS языку изза большей развитости последнего.
Примеры в студию.
Это шутка такая? На жабе для десктопа разве только развесистые профессиональные приложения писать не требующие высокой производительности. А так все гуи-приложения что видел на любом жабовском фреймворке для десктопа ощутимо неспешны.
Не, конечно аполегеты утверждают иное, но в реальности я ещё ни разу не видел нормально работающее десктопнее жабо-приложение: медленно запускается, ощутимо медленно открываются окошки, ощутимо медленно происходит реакция на всякие нажатия и т.п.
Как тут уже многие говорили: монстр Qt (реально монстр и тормоз если сравнить его с фреймворками XX века!) становится маленьким и юрким, когда его начинают сравнивать с Electron'ом и JavaFX…
Запустил я как-то её на стареньком ноуте с 2 гигами памяти на HDD… Ага, конечно, сносная — если у вас ресурсов немеряно.
А на какой девелоперской машине их сейчас мало?
Если же ваше приложение рассчитано на более широкую аудиторию, то этот подход — не очень годится: если это ваше основное приложение, которым вы деньги зарабатываете, то вы можете ему это простить и прикупить для него «лишние» 4-8-16GB памяти, но если это какой-нибудь проигрыватель музыки — то вы, скорее всего, предпочтёте что-нибудь другое…
На старом ноуте с HDD тормозит все.Позвольте мне не поверить. Visual Studio 6 или какой-нибудь Delphi 2.0 там «летают».
В особенности «програмные монстры» типа браузеров и IDE.В случае с браузерами всё в меньшей степени зависит от браузеров и в большей — от сайтов, которые вы посещаете. Какой-нибудь gcc.gnu.org или там lwn.net тоже нифига не тормозят несмотря на «жалкие» 1GB памяти и «несчастный» Atom, а вот банк-клиент на каком-нибудь «моднючем» фреймворке — тут да, без слёз не взглянешь.
Обычные приложения на java (не монстры) даже на слабом железе работают быстро.Не заметил. Опять-таки: uTorrent на этом самом Атоме летает и систему не грузит, как Vuze запустишь — так она только им и занята. Даже если там не так много активности.
У Java-приложений много достоинств, но скорость работы и потребление ресурсов у них ужасны. То, что Electron побил все рекорды и теперь простенький редактор занимает не пару мегабайт в памяти, а пару гигабайт не означает, что Java вдруг стала менее жрущим монстром.
А запуск? 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), а современными — оно будет жрать пару гигов?
Что и где «пошло не так»?
Я каждый день использую Gogland, чуть реже CLion.
Софт от Jet Brains это типичный образчик «развесистого профессионального приложения». Gogland, в принципе, работает сносно, т.к. Go сам довольно простенький. А вот CLion иногда еле-еле ворочается на не самых больших кусках.
Долой хайп, пишем на брейнфаке.
Просто потому что мне нравится брейнфак, а не потому что хайп не зря.
А так нет =)
bitbucket.org/JavaSabr/jme3-spaceshift-editor
mvvmFX на GitHub
У меня Intellij IDEA запускается за 10 сек, а Visual Studio за 1 мин 20-30 сек (сами проекты не открываются). NetBeans за 30 сек. То время, когда написанное на Java быстрее, чем на c++
У меня Intellij IDEA запускается за 10 сек, а Visual Studio за 1 мин 20-30 сек (сами проекты не открываются).Серьёзно? Это Visual Studio 6.0 у вас на машинке, где IDEA за 10 секунд запускается больше минуты стартует???
То время, когда написанное на Java быстрее, чем на c++Последняя версия Visual Studio, написанная на C++, это, я таки извиняюсь, Visual Studfio 6.0. После этого там завёлся C# — и чем дальше, тем больше (в первых версиях Visual Studio .NET на нём пара Wizard'ов, в Visual Studio 2017 — почти весь интерфейс). Результат немного предсказуем.
То, что Intellij IDEA написана весьма и весьма качественно — общеизвестно. Но, пожалуйста, не нужно её сравнивать с нативными C++-программами.
VS 2015, windows 7, RAM 4GB, HDD. Проект с шаблоном asp.net mvc в нем слишком долго создается вплоть до минуты, даже в NetBeans до 15 сек занимает создание проекта с шаблоном web.
На что меняют? На то, что и было: C/C++. Но Sun успел изрядно засрать кодовую базу компонентами на Java, работы много.
В версиях до релиза (сейчас не проверял), игра скачивалась в двух частях — сначала лаунчер, а потом в нем авторизация и докачка основного тела игры, ну в общем все как обычно.
Суть прикола — лаунчер сделан на электроне, но закачивает он игру, которая тоже на электроне, даже файлы те же самые! Но при этом игра занимает МЕНЬШЕ лаунчера, КАРЛ! %) Примерная пропорция — где-то 150 метров на лаунчер и 120 на игру. :D
Единственное объяснение (если оно кого-то заинтересует) — в лаунчере замастрячили интро-видос в фуллхд и много анимированного графона на задник и кнопки.
Oracle чуть не испортила всё с самого начала, приступив к созданию особого, декларативного языка, который предполагалось использования для создания UI приложений...следовало бы написать чуть-чуть иначе. А именно: «Sun чуть не испортила всё с самого начала...»
Это солнечные зачем-то ввели скриптовой язык для JavaFX. На мой взгляд — неразумное решение. Oracle же, после покупки Sun, всё это стряхнул и начал чуть ли не с нуля, сделав замечательный инструмент — новый JavaFX-2. Ну и далее 8 и 9.
Мне не пришлось пока писать софт на JavaFX для продакшена, но для своих проб я его использовал. И мне он исключительно нравится. Реальным конкурентом вижу только Qt но… С++ таки сложный язык. И он постоянно меняется в сторону усложнения. В своё время я писал на нём лет 10, то есть, я в нём не новичок, хотя и подзабыл уже. Опять же много нового появилось. Но даже после этого, попробовав Qt, просто руки опускаются когда приходится слазить с Java, и особенно с IntelliJ IDEA. На Java под IntelliJ код словно сам стекает из мозга на экран.
А что касается Javascriptа. Это адский ад, а не язык для промышленной разработки. Тот человек, который его придумал, вряд-ли предполагал, что на нём будут писать куски кода длиннее 20-30 строк. Но чудеса движения цивилизации неисповедимы. К счастью, Микрософт тут внёс полезное в индустрию. А именно — придумал и реализовал TypeScript. А это уже заметный шаг в сторону сил света.
Последний мой проект идёт на Angular 4, но это не десктоп. И я по прежнему внимательно слежу за JavaFx. Читаю блог одного из разработчиков с новостями. Ничего про глобальное прекращение разработки не упоминалось. Так же слежу за твиттерами людей, работающих с/для этой платформы.
Про Электрон не знаю ничего. И пока не очень привлекает. На мой взгляд какой-то очередной странный зигзаг индустрии. Как Air.
% java -jar logfx.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/athaydes/logfx/LogFX : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
...
Интересно, это только у меня на openSUSE Leap 42.3, или у всех с примером из статьи?
Портабилити не совсем впечатляет...:(
Портабилити не совсем впечатляет...:(
Портабилити — это переносимость между платформами. Также есть понятие обратной совместимости — когда некое приложение скомпилированное на старой версии платформы продолжает работать на новой версии. А вот такое, что бы что-то скомпилированное на новой продолжало работать на старой версии, часто не бывает, ибо новое, оно потому и новое, что там что-то добавлено. Как же оно будет работать на старой версии если там этого нового ещё не было?!
Скажи «нет» Electron! Пишем быстрое десктопное приложение на JavaFX