Комментарии 119
Ваше приложение это аналог Postman?
Мы пересекаемся по функционалу с постманом. Однако, у нас есть ключевые отличия:
1) Возможность создавать сценарии запросов (создать сущность -> получить сущность чтобы проверить, что она существует -> удалить сущность)
2) Создания тестов без программирования. Мы имеем конструктор assertion-ов, который позволяет создавать их из UI. В случае сложных тестов вы так же можете написать скриптовый assertion на javascript.
3) Человекочитаемый формат проектов (базирующийся на yaml). Это позволяет синхронизировать проект через системы контроля версий с возможностью code-review и т.д.
4) Автокомплит переменных, заголовков, протоколов и т.д.
1) Возможность создавать сценарии запросов (создать сущность -> получить сущность чтобы проверить, что она существует -> удалить сущность)
2) Создания тестов без программирования. Мы имеем конструктор assertion-ов, который позволяет создавать их из UI. В случае сложных тестов вы так же можете написать скриптовый assertion на javascript.
3) Человекочитаемый формат проектов (базирующийся на yaml). Это позволяет синхронизировать проект через системы контроля версий с возможностью code-review и т.д.
4) Автокомплит переменных, заголовков, протоколов и т.д.
По поводу 3 пункта. Если это будет действительно удобно, хотя на примере Postman не совсем представляю себе как это возможно, то это будет наверное основной киллер-фичей.
Жду от вас статью уже для тестировщиков, где вы наверное расскажите про этот пункт и п.1 подробнее.
Жду от вас статью уже для тестировщиков, где вы наверное расскажите про этот пункт и п.1 подробнее.
Да, мы как раз собираемся опубликовать статьи тут. Более того, они уже есть в английской версии в нашем блоге:
testmace.com/blog/2019/01/28/testmace-beta-features-overview-part-1
testmace.com/blog/2019/01/28/testmace-beta-features-overview-part-2
Русскую версию выложим тут в течении недели наверное.
testmace.com/blog/2019/01/28/testmace-beta-features-overview-part-1
testmace.com/blog/2019/01/28/testmace-beta-features-overview-part-2
Русскую версию выложим тут в течении недели наверное.
Судя по github.com/dotnet/wpf/issues/48#issuecomment-444198305 оно не очень кроссплатформенное и вроде даже не собирается. Насчет остального тоже, многопоточность вполне честная, пусть и не такая удобная как в C#, да и коммьюнити у js достаточно мощное и готовых решений хватает
Перепроверил — вы правы. Тогда — только AvaloniaUI.
С каких пор они стали кроссплатформенными?
Когда говорят о кроссплатформенности на .NET всегда упомянают AvaloniaUI, однако она в бете
Было бы интересно прочитать продолжение статьи через 6-8 месяцев активной разработки, когда будут уже сформированные процессы, возможно какие-то метрики и относительно большой опыт командной разработки. Тогда можно было подробно написать про объективные плюсы и муинусы.
Прелесть Electron состоит в том, что можно перенести наработки (как функциональные, так и с точки зрения бизнес-процессов) из web почти без изменений. Поэтому я думаю, что electron в этом плане нам палки в колеса вставлять не будет.
Хотя кажется что все что работает в браузере(Chrome), будет работать и в electron — это не совсем так.
Например window.open работает с другим API, и даже если сделать nativeWindowOpen он не будет полноценно работать
В случае использования авторизации через фейсбук, у открываемого окна не будет доступен window.opener, что ставит крест на возможности авторизации(хотя для electron@2 есть воркэраунд)
Других значимых отличий по части браузерной работы я за полгода пока не нашел
Например window.open работает с другим API, и даже если сделать nativeWindowOpen он не будет полноценно работать
В случае использования авторизации через фейсбук, у открываемого окна не будет доступен window.opener, что ставит крест на возможности авторизации(хотя для electron@2 есть воркэраунд)
Других значимых отличий по части браузерной работы я за полгода пока не нашел
Прелесть Electron состоит в том, что проблемы разработчика перекладываются на плечи конечного потребителя (пользователя). Для меня, как воспитанника ещё старой инженерной школы, профессиональным кредо являются слова: «потребителю задача упрощается, инженеру — усложняется».
А Electron, позволяя разработчику «перенести наработки из web почти без изменений», непомерно и неоправданно жрёт ресурсы конечного потребителя. Именно из-за таких парадигм мы и не имеем в конечной производительности информационных систем того экспоненциального роста, который демонстрируют формальные показатели (а-ля закон Мура)!
А Electron, позволяя разработчику «перенести наработки из web почти без изменений», непомерно и неоправданно жрёт ресурсы конечного потребителя. Именно из-за таких парадигм мы и не имеем в конечной производительности информационных систем того экспоненциального роста, который демонстрируют формальные показатели (а-ля закон Мура)!
На данный момент многие популярные приложения написаны на Electron
Не использую ни одно из перечисленных приложений именно из-за того, что они на Electron. Мне, знаете ли, «по долгу службы» нужно держать две виртуалки, немаленькую базу данных, поисковый движок с индексом этой базы и одновременно с этим как-то позволять себе котиков на ютубе посмотреть и в кс пострелять. А два-три работающих Electron-приложения могут почти переплюнуть это всё по потреблению памяти. Спасибо, не надо.
Давно мечтаю о нативном аналоге Postman.
Отчасти согласен, что самой большой претензией является сравнительно большое потребление памяти. Но. Смею заметить, что та же insomnia или постман потребляют в районе 500 МБ оперативной памяти. Для людей, который активно используют подобного рода инструменты подобные показатели — копейки. Зато функционал с лихвой перекрывает данный недостаток. Возможно в вашем случае этот функционал не критичен и вам достаточно того же curl
Тем не менее 500 МБ для приложений подобного рода — это очень дофига.
такое потребление это фейл. Определённые приложения могут возложить МПХ на своих пользователей в силу своей уникальности, что конечно же не делает им чести. Как правило это либо приложения, ставшие популярными в веб-версии, и выпустившие _такой_ клиент в качестве бонуса, либо приложения, уже имеющие огромную аудиторию, и перешедшие на электрон при очередном обновлении. Люди в силу инертности, привычки и базы контактов будут терпеть.
Для стартапа это на мой взгляд непозволительно.
Для стартапа это на мой взгляд непозволительно.
Тут я с вами не согласен. Ну начнем про стартап. Electron очень хорошо подходит для быстрого старта (большое количество специалистов, компонентов, текущие компетенции команды) — самое то для стартапа. Во-вторых, про то, что пользователи «терпят» — опыт атома, vs code, git kraken говорят об обратном, сообщества растут и развиваются. Да и найдите приложение, которое сфейлилось исключительно от большого потребления памяти? Что-то не припомню. Гораздо важнее, чтобы инструмент решал повседневные задачи пользователей. И, по моему скромному мнению, если инструмент успешно справляется с поставленными задачами по сравнению с конкурентами, то некоторую прожорливость (некатастрофическую) ему простят. Вы же не променяете IDE от Jetbrains на Notepad++ только из-за памяти, правда?
IDE от Jetbrains, это совершенно другой весовой категории приложения.
И, к счастью, их на electron ещё не переписали, и надеюсь, не станут никогда.
Они сравнимы вполне по потреблению ресурсов с разными Nеtbeans и Eclipse которые их конкуренты потенциальные.
А вот Atom или VSCode уже можно посравнивать с нативными редакторами, и они явно проигрываеют им по потреблению ресурсов. И пользуются, как раз, в этой нише, не только ими, и даже не в основном ими в итоге хоть они и довольно популярны…
И, к счастью, их на electron ещё не переписали, и надеюсь, не станут никогда.
Они сравнимы вполне по потреблению ресурсов с разными Nеtbeans и Eclipse которые их конкуренты потенциальные.
А вот Atom или VSCode уже можно посравнивать с нативными редакторами, и они явно проигрываеют им по потреблению ресурсов. И пользуются, как раз, в этой нише, не только ими, и даже не в основном ими в итоге хоть они и довольно популярны…
А почему бы не сравнить тот же VSCode с Eclipse или Netbeans? У VSCode есть все фишки IDE.
НЛО прилетело и опубликовало эту надпись здесь
VSCode, увы, не является IDE. "Integrated" из аббревиатуры не хватает. Все расширения живут своей жизнью и общаются с вскодом по LSP. В такой ситуации сделать расширение, которому, скажем, нужна из OmniSharp информация о проектах в солюшене, просто напросто невозможно. Это, кстати, одна из причин, по которым у Avalonia до сих пор нет расширения под вскод, нужно самостоятельно парсить солюшен, самостоятельно пинать мсбилд, итп.
В итоге как всегда tl;dr: мы выбрали электрон, потому что так тупо дешевле.
Если на мак — paw.cloud
Попробуйте SoapUI. Не совсем нативное (java), но по сравнению с postman'ом он гибче и имеет намного больше возможностей.
Тут один товарищ пишет аналог Postman на джаве и выглядит оно очень не плохо, правда функционала не хватает пока. Нужны контрибьюторы.
Нет сомнения в том, что и по памяти и по перформансу в целом оно уделает любые электрон монстры.
Everest
Нет сомнения в том, что и по памяти и по перформансу в целом оно уделает любые электрон монстры.
Everest
При том, что вы очень быстро оказываетесь на рынке, вы получаете колоссальный техдолг. Этот техдолг — ужасающее непредсказуемое урчащее. Как только ваше приложение начнёт использоваться по назначению (т.е. в работе), окажется, что оно:
а) имеет latency до нескольких сотен (тысяч?) милисекунд в те моменты, когда этого хочется v8
б) ест память так, как будто оно запущено на тьюринг-машине с бесконечной лентой
в) заедает процессором.
Чем больше пользователи будут его использовать, тем более негативным будет их опыт. При этом пути назад почти не будет, потому что в разработку вложено много сил.
а) имеет latency до нескольких сотен (тысяч?) милисекунд в те моменты, когда этого хочется v8
б) ест память так, как будто оно запущено на тьюринг-машине с бесконечной лентой
в) заедает процессором.
Чем больше пользователи будут его использовать, тем более негативным будет их опыт. При этом пути назад почти не будет, потому что в разработку вложено много сил.
Ну уж вы сгустили краски). Тот же vs code — одна из самых популярных IDE на сегодняшний день — вполне себе шустро работает. Но то есть задержек нет даже когда я активно набираю и «требую» немедленного автокомплита) По поводу потребления процессора — тоже не вижу однозначной связи с electron. JS достаточно шустр. По поводу памяти нашу позицию я разъяснил в статье
задержек нет даже когда я активно набираю
Другие пользователи с вами почему-то не согласны https://github.com/Microsoft/vscode/issues/27378
По поводу потребления процессора
А помните, когда-то давно мигающий курсор в VS Code кушал 13% процессора просто так?
А помните, когда-то давно мигающий курсор в VS Code кушал 13% процессора просто так?
Пробежался по статье. В конце нашел следующее
Но в конце концов разработчики из Microsoft всё-таки решили вернуться на старый добрый JS-метод setInterval для мерцания курсора — и потребление CPU сразу снизилось в несколько раз.
Ну то есть кривая реализация. Что поделать, всякое бывает, и не только на js.
Другие пользователи с вами почему-то не согласны github.com/Microsoft/vscode/issues/27378
Опять таки, исходя из этого всех собак надо повесить только на electron?) Замечу, что фризы возникают и в Visual Studio и в Jetbrains и в VS Code с примерно одинаковой частотой. Технологии диаметрально противополжные — проблема одна.
Не очень сгустили. Пока Скайп был на Делфи, он нравился почти всем. Переписали на Электрон и он окончательно скатился в УГ (к моему большому сожалению, мне Скайп всегда нравился). У меня постоянные лаги и глюки на довольно хорошей машине (i7+gtx 960, 16 gb). На Андроиде Скайп работает просто отвратительно.
По поводу скайпа я с вами полностью согласен, совсем не радует во всех смыслах. Ну так и на скайпе мир клином не сошелся) В комментах упомянуты более интересные приложения на electron-е.
Однако же плохих приложений на электроне на много больше чем хороших. Сразу вспоминается Viber и пресловутая Слака. Да vscode изрядно фризится на механических винтах, не многим меньше jetbrains (если меньше).
Ну и надо признать, что веб технологии с реактами, редаксами, npm-ами, css-ом вот этим всем выглядят просто чудовищно уродливо в сравнении с популярными нативными фреймворками для десктопных gui приложений
Ну и надо признать, что веб технологии с реактами, редаксами, npm-ами, css-ом вот этим всем выглядят просто чудовищно уродливо в сравнении с популярными нативными фреймворками для десктопных gui приложений
НЛО прилетело и опубликовало эту надпись здесь
Это вопрос интересный. У electron хорошая поддержка в лице web-инфраструктуры. Как следствие, большое разнообразие интерфейсных решений, отработанные процессы, потенциально большее количество специалистов, да и про кроссплатформенность не стоит забывать. Однако electron конечно не самоцель: если удобнее на Delphi — пишите на Delphi
Обезьянки, выучившие пару глав учебника по JS это не специалисты. И то что из под них выходит использовать не хочется ну вот прям совсем. На данный момент вообще не использую приложения на электроне, т.к. не хочу менять компьютер, только потому что на нем условный текстовый редактор тормозит. И вашим приложением тоже не буду пользоваться. Благо пока нативных приложений хватает.
Обертка для веб-сайтов имеет свою узкую нишу применения. Не надо его использовать везде. Да тот же скайп как пример. Нативное приложение ресурсы не ело и было отзывчивым и удобным. Как только запихнули в электрон, так пользоваться стало жутко неудобно. Пришлось отказаться.
Обертка для веб-сайтов имеет свою узкую нишу применения. Не надо его использовать везде. Да тот же скайп как пример. Нативное приложение ресурсы не ело и было отзывчивым и удобным. Как только запихнули в электрон, так пользоваться стало жутко неудобно. Пришлось отказаться.
200 мегабайт… когда-то я работал на машине, которая имела 0.5 Мб памяти… она обслуживала 50 рабочих мест онлайн, рассчитывала зарплату для предприятия со штатом около 5000 человек. Там была кадровая база и много чего. А жило все это на двух жестких дисках по 20 Мб каждый. Технический прогресс, однако…
НЛО прилетело и опубликовало эту надпись здесь
Все похожие статьи можно существенно сократить:
Почему мы выбрали электрон?
Здравствуйте.
Дешевле.
Спасибо за внимание.
Аргумент веский, но КМК подходит не для всех приложений. Для обычных пользователей может и зайдет — они не разбираются электрон это или не электрон. Для разработчиков/админов и.т.д. только если приложение предоставит им больше возможностей чем конкуренты.
Как-то обсуждали электрон и сошлись во мнении что: «За деньги я вам напишу что угодно и на чем угодно, но сам использовать не буду».
Так, мысли вслух.
Почему мы выбрали электрон?
Здравствуйте.
Дешевле.
Спасибо за внимание.
Аргумент веский, но КМК подходит не для всех приложений. Для обычных пользователей может и зайдет — они не разбираются электрон это или не электрон. Для разработчиков/админов и.т.д. только если приложение предоставит им больше возможностей чем конкуренты.
Как-то обсуждали электрон и сошлись во мнении что: «За деньги я вам напишу что угодно и на чем угодно, но сам использовать не буду».
Так, мысли вслух.
Только не «дешевле», а «большую часть оплатят пользователи», ежедневно, каждый. А нам-то да, выйдет дешевле.
Стоимость разработки нативных кросплатформенных приложений может быть настолько дороже (как минимум в нашем случае), что разработку лучше не начинать вообще. Вы считаете, что отсутствующее приложение лучше, чем приложение, которые покрывает кейсы, не побоюсь этого слова, большей части пользователей?
Не нужно сказок. Delphi/Лазарус существенно дешевле разработки на JS, по собственному опыту, используем и то и другое у себя в компании довольно давно (Delphi — 15 лет, JS — 10). Delphi/Лазарь сейчас работает практически на всех платформах, от утюгов (Лазарь, распбери — запросто) до Веба (есть пяток решений, от транспилляторов pas > js до ExtJS обёрток). Работает практически с одним кодом. Мы пишем в продакшне, Винда, Линукс, Веб (частично — 'чистый' JS, частично — UniGUI).
Всё нативное, само собой.
Лазарус, если что, полностью бесплатный. Delphi бесплатный с ограничениями по доходам.
Всё нативное, само собой.
Лазарус, если что, полностью бесплатный. Delphi бесплатный с ограничениями по доходам.
Ну как ты вы лихо все приложения под одну гребенку подвели. Ну как минимум, нам нужен редактор для работы с подсветкой синтаксиса, автодополнением, статическим анализатором js кода, наличием встроенных подсветок синтаксиса. Плюс должна быть поддержка запуска скриптов на одном из популярных язков (jvm-based или js). Нас не устраивает как выглядят нативные компоненты, поэтому нам бы хотелось выбрать что-то стороннее.
Ну и в завершении по поводу дешевизны разработки на Delphi/Lazarus. Зашел на сервис зарплат в моем круге (лучше, извините, ничего не придумал) чтобы оценить во сколько раз отличается количество delphi и js разработчиков. Delphi — 24 разработчика, js — 9147 разработчика. Разница просто колоссальная и она в целом отражает ситуацию на рынке — на js найти разработчика проще, чем на delphi, я думаю вы спорить не будете. Ну а между проще и девешле фактически можно ставить знак равенства.
В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.
Ну и в завершении по поводу дешевизны разработки на Delphi/Lazarus. Зашел на сервис зарплат в моем круге (лучше, извините, ничего не придумал) чтобы оценить во сколько раз отличается количество delphi и js разработчиков. Delphi — 24 разработчика, js — 9147 разработчика. Разница просто колоссальная и она в целом отражает ситуацию на рынке — на js найти разработчика проще, чем на delphi, я думаю вы спорить не будете. Ну а между проще и девешле фактически можно ставить знак равенства.
В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.
В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.По собственному опыту. Выхлоп отличного Delphi программиста против выхлопа отличного JS. Зарплата получается примерно одинаковая, но отдача не сопоставима, увы.
Людей найти можно и тех и других.
Большинство из того, что вы перечислили скорее всего есть в виде готовых Delphi компонент. Собственно — сама Delphi (IDE) написана на Delphi.
Каждое приложение на electron потребляет какое-то совершенно невероятное количество ресурсов: оперативной памяти и процессорного времени, что никак не коррелирует со сложностью и функциональностью приложения. Каждое приложение на электроне тормозит и фризится даже на мощных рабочих станциях. Даже хвалёный тут и везде vscode. Одно, второе, третье приложение на электроне и вот уже мощная рабочая станция превращается в тыкву… гори в аду, electron!
НЛО прилетело и опубликовало эту надпись здесь
Читаю комментарии и прямо радуюсь что все таки не один я такой. Если вижу что приложение имеет в своей основе электрон, react native и подобные технологии быстрого приготовления — удаляю, оставляю только если нет альтернатив или приложение не вот прям обязательно по каким то причинам.
Надеюсь, разум всё таки победит. Динозавры же вымерли? Есть надежда, что и текущее состояние дел не на всегда.
НЛО прилетело и опубликовало эту надпись здесь
Да, PWA это отдельный ужас и боль. Если серьезно — то альтернативы web based фреймворкам и технологиям надеюсь в скором времени появятся. За Microsoft не слежу, хотя из долетавших до меня слухов он в этом направлении двигается, но например под мобилки от google вполне годный по архитектурной задумке flutter выходит. Да, пока только вышел, но в целом на мой взгляд перспективы есть у технологии как в плане быстрой и дешевой разработки, так и в плане производительности и расширяемости, тем более что можно подключать вполне написанные на других языках вещи. Также любопытно куда kotlin двинется. Ну а то что я стараюсь не пользоваться по возможности электрон/реакт нейтив приложениями — тут конечно не всегда меня такие продукты не устраивают по своим потребительским качествам (не зря себе комп собирал за 3 зп), но таким образом я кладу очередную песчинку на чашу нативных и компилируемых технологий против веба.
НЛО прилетело и опубликовало эту надпись здесь
React Native в итоге все же исполняет js, да еще и с мостом к нативу, в отличие от флаттера который по примеру всяких фреймворков для игр рендерит все сам, не имеет никаких мостов, да и код даже сейчас уже практически в натив под железо компилируется (хотя там вроде есть отдельные но) если не в дебаг сборке. Насчет флаттера под десктоп — есть вероятность что появится (учитывая то что для веба он вполне оффициально пилится и есть репа с flutter-desktop, пусть судя по всему просто эксперимент)
А PWA это все те же js+html+css.
А PWA это все те же js+html+css.
НЛО прилетело и опубликовало эту надпись здесь
Почему медленнее? Как раз из за того что нет моста он и получится быстрее. Есть мосты к вещам вроде геолокации и подобным, но между кодом и UI мостов как раз нет вообще (хотя из того что я понимаю есть деление что рендерингом skia занимается, а код исполняется тот что скомпилирован из дарта — но по факту там нет накладных расходов практически, ибо это все равно что из C какую нибудь либу дергать).
«PWA это все те же js+html+css» — что означает все те же проблемы что и с вебом в виде зависимости от js (ибо даже при транспиляции именно js будет в итоге), тормозов (несмотря на jit'ы)
«PWA это все те же js+html+css» — что означает все те же проблемы что и с вебом в виде зависимости от js (ибо даже при транспиляции именно js будет в итоге), тормозов (несмотря на jit'ы)
И чем же PWA — ужас и боль?Яндекс.Избач (дополнение для Яндекс.Метрики) — не только мониторит действия пользователей на сайте, но и вероломно шарится в их компьютерах. Ура! (надеюсь шутка).
А я тут посчитал, у меня на ноуте прямо сейчас пять приложений на Electron работают и ничего не тормозит, ОЗУ больше половины свободно. Что тут все обсуждают не понятно)
Дайте угадаю, стоимость вашего железа 50к+?
Это до тех пор, пока вы не начнёте в этих приложениях работать. У меня рабочее окружение — Slack, Skype, Postman и VSCode. Примерно через 7 часов после запуска эта братия начинает дружно подвисать и тормозить различными способами. Это на 9700К и 16 гигах оперативки! Причём самое странное то, что по монитору ещё есть пару гигов свободной памяти и процессор не нагружен. Есть подозрение, что вся эта электронная муть своим жеесом под конец дня дико фрагментирует оперативку, отчего и фризы возникают. Перезапуск лечит ещё на 2-3 часа, дальше приходится перезагружаться. Это мне теперь нужно ещё 16 гигов докупать, чтобы гонять 4 электрона без проблем хотя бы часов 10?
Ну я, конечно, немного масла в огонь подлил, проблема мне в общем понятна, но меня самого всерьез никогда не беспокоила. Таких проблем как у вас у меня не возникает точно, на вашем месте я бы все проклял :). Из всех Electron приложений, включая Skype, притормаживал только Gitkraken и то на данный момент все уже исправили. Система перезапускается только в момент обновлений, когда без этого никак, все остальное время спит. То есть неделями все работает без перезапусков. ОЗУ 16 гб, если б было 8, наверное, все было бы грустнее.
Я как-бы точно не диагностировал виновника, но большую часть сьедает Slack (там 2 организации по 50+ чатов) и, естественно, VSCode (легаси проект на NodeJS с файлами по 8 тысяч строк кода). Но то, что виновник — электрон, я уверен на 100%. Если сидеть в телеграмме и XCode, то даже с утечками памяти в икскоде (когда приходится убивать SourceKit, сожравший 13+ гигабайт) можно более-менее спокойно работать весь день.
C#, TypeScript, Go
Могу я узнать, почему вы не смотрели в сторону jvm?
Не сильно знакомы с данной экосистемой
Рискну показаться категоричным, но на сегодняшний день действительно сильными кроссплатформенными десктоп инструментами (с поправкой в том числе и на количество доступных специалистов на рынке) являются Qt (C++) и OpenJFX (Java и со.). Все остальные либо сырые, либо немного устарели, либо просто «модные».
… на сегодняшний день… (с поправкой в том числе и на количество доступных специалистов на рынке)… и OpenJFX ..
Я, конечно, практически не изучал данный вопрос, но разве по FX есть достаточное количество вакансий\проектов\специалистов? Да даже хотя бы обширное коммьюнити с достаточным количеством мануалов и гайдов?
Чисто по внешнему впечатлению, развитие этого продукта остановилось, им никто не интересуется, статьи о нём не пишутся на тот же хабр. Не слышал о нём за последние два года ни разу, вот от вас только, хотя постоянно слежу за общим фоном Java-мира.
Пробовал изучать FX и просто по удобству использования использования и удобству разработки сравнивал с шарповыми WinForm\WPF, которые под mono спокойно запускались на линуксах в том числе. Сравнивал чисто в пользовательском смысле.
И, FX безумно проигрывал по скорости разработки и удобству. Безумное количество лишних действий, которые не удобны в том числе из SceneBuilder. И сам SceneBuilder тормознутое, топорное и чудное… было пару лет назад.
Я, разумеется, его не правильно готовил, с этим спорить не приходится, тем не менее — общее состояние дел как-то изменилась за эти два года или всё примерно на том же уровне? Использовал FX-8
Хайпа давно никакого нет, потому как сейчас десктоп инструменты не провоцируют хайпы в принципе. Столица плавно переместилась в Веб. Опять же — инструменту уже 8 лет, он вполне зрелый, чего тут хайпать? Недавно, правда, был один хайпец. Начинаяя с версии Java 11, JavaFX больше не часть JDK. Она стала отдельным модулем, называется OpenJFX и перешла в поддержку компании Gluon и OpenJDK комьюнити. Доступна из maven репозитория и версионно с JDK больше не связана. Если действительно следите за общим фоном Java-мира, то в конце прошлого году точно должны были слышать. Штаб находится тут. На Амазоне вы легко найдёте более сотни разных книг/учебников.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть. Как и везде. SceneBuilder я не использовал. Сейчас вообще десктоп инструменты используются значительно реже. Я также использую данный фреймворк лишь эпизодически. Хотя и давно. Как он может безумно (!) проигрывать хоть чему-то, мне не понять. Обычно так эмоционально выражаются апологеты другой платформы (скажем .NET), знакомые с Java инструментами крайне поверхностно, но изначально идеологически настроенные против.
Из своего опыта, могу сказать, что некоторое отчуждение испытывали люди, которые впервые сталкивались с более новой концепцией построения GUI. JavaFX использует некий базовый контейнер-подмосток, на котором может быть выстроена одна иди несколько сцен, состоящих из любых графических элементов. Каждую сцену, вместе со всем её содержимым, можно как угодно трансформировать (масштабировать, скручивать, поворачивать...), анимировать, менять цвета и яркости. И даже источники света размещать. Некая форма с кнопками это всего лишь частный случай сцены. А в целом получается очень гибкая графическая конструкция (и 3D). Идея не нова, таким же образом построены Qt и WPF. Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным. К чему такая мощь для кнопочек? Ну только лишь для кнопочек может и ни к чему.
Ещё одна не всем привычная и пугающая новичков фишка — реактивность свойств. Любое свойство графического объекта может быть «сцеплено» с другим свойством другого объекта. То, в свою очередь, с неким свойством третьего и так далее. Меняя одно свойство, автоматически меняются связанные. Примерно как пересчитываются связанные клетки в Excel. Ну и сцена обновляется. Идея не нова, она положена в основу реактивного программирования, но если вы не имеете навыков такого рода построения интерфейса, то… вы опять же сразу не оцените всю мощь и гибкость такого подхода. И будете по привычке искать какие-нибудь события для того, что бы их «как обычно» обработать.
Есть ещё одна особенность, которую некоторое количество людей люто, патологически ненавидят. JavaFX — фреймворк класса 'lightweight'. Другими словами — все свои контролы он рисует сам и не использует родные контролы операционной среды. Ну и стало быть интерфейс может выглядеть не как родной, нейтивный. Также устроен и Qt. И старенький Swing.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть. Как и везде. SceneBuilder я не использовал. Сейчас вообще десктоп инструменты используются значительно реже. Я также использую данный фреймворк лишь эпизодически. Хотя и давно. Как он может безумно (!) проигрывать хоть чему-то, мне не понять. Обычно так эмоционально выражаются апологеты другой платформы (скажем .NET), знакомые с Java инструментами крайне поверхностно, но изначально идеологически настроенные против.
Из своего опыта, могу сказать, что некоторое отчуждение испытывали люди, которые впервые сталкивались с более новой концепцией построения GUI. JavaFX использует некий базовый контейнер-подмосток, на котором может быть выстроена одна иди несколько сцен, состоящих из любых графических элементов. Каждую сцену, вместе со всем её содержимым, можно как угодно трансформировать (масштабировать, скручивать, поворачивать...), анимировать, менять цвета и яркости. И даже источники света размещать. Некая форма с кнопками это всего лишь частный случай сцены. А в целом получается очень гибкая графическая конструкция (и 3D). Идея не нова, таким же образом построены Qt и WPF. Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным. К чему такая мощь для кнопочек? Ну только лишь для кнопочек может и ни к чему.
Ещё одна не всем привычная и пугающая новичков фишка — реактивность свойств. Любое свойство графического объекта может быть «сцеплено» с другим свойством другого объекта. То, в свою очередь, с неким свойством третьего и так далее. Меняя одно свойство, автоматически меняются связанные. Примерно как пересчитываются связанные клетки в Excel. Ну и сцена обновляется. Идея не нова, она положена в основу реактивного программирования, но если вы не имеете навыков такого рода построения интерфейса, то… вы опять же сразу не оцените всю мощь и гибкость такого подхода. И будете по привычке искать какие-нибудь события для того, что бы их «как обычно» обработать.
Есть ещё одна особенность, которую некоторое количество людей люто, патологически ненавидят. JavaFX — фреймворк класса 'lightweight'. Другими словами — все свои контролы он рисует сам и не использует родные контролы операционной среды. Ну и стало быть интерфейс может выглядеть не как родной, нейтивный. Также устроен и Qt. И старенький Swing.
Ох, благодарю за развёрнутый ответ.
Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.
Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.
Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть.
Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным
Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.
Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.
Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.
В JavaFX, как и в Swing, при прочих равных, стараются избегать абсолютного позиционирования (разные платформы, разные шрифты, разное разрешение...), а предпочитают использовать специальные layout managers. Это контейнеры, которые расставляют расположенные на них визуальные объекты по определённому закону. В виде сетки, разбивая на некие группы, поддерживая нужные расстояния между ними, меняя их размер с изменением размера охватывающего контейнера ну и прочее. Есть несколько стандартных, есть написанные сторонними людьми. Ну и свой можете написать. SceneBuilder также предлагает класть их как подложку, что некоторых может озадачить, если раньше не сталкивались с таким подходом.
По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Да ну какое там радужно. После того, как на рынок вышли мобилы, и там три ключевых разработчика ОС не смогли найти общего языка, и javascript оказался единственным кроссплатформенным «клеем»…
Qt пошла по рукам. JavaFX стагнирует. Javascript возомнил себя победителем, и теперь все новые проекты это чисто Франкенштейны типа Электрона. Цивилизация куда-то не туда свернула, пытается выкарабкаться всякими там TypeScript…
Оно может и неплохо, что FX ушла в Open мир. :)
Qt пошла по рукам. JavaFX стагнирует. Javascript возомнил себя победителем, и теперь все новые проекты это чисто Франкенштейны типа Электрона. Цивилизация куда-то не туда свернула, пытается выкарабкаться всякими там TypeScript…
Оно может и неплохо, что FX ушла в Open мир. :)
И Delphi
Зря передергиваете. В соседней ветке спор по теме на чем дешевле разрабатывать так и не был разрешен.
sciter не смотрели для вью? в связке хоть с чем для бизнес-модели (c++, c#, delphi и т. д.). Вроде интересное решение.
Как-то пытался сделать простое pet-приложение на нем. В итоге столкнулся с тем, что Sciter достаточно сырой под Linux, и вокруг него все равно приходится городить огород из кусков WinAPI/GTK+. Ну и в минусы: закрытые исходники, один разработчик (который, впрочем, достаточно оперативно фиксит баги и пилит фичи по запросу), статическая линковка и доступ к исходниками за деньги. В общем, для некоммерческого хобби я бы его взял, для разработки коммерческого приложения, с которого собираюсь получать доход — нет.
Потому что у вас нет совести. (Но это нормально — совесть бизнесу обычно мешает.) Всё остальное (написанное в статье) — вторично.
Эх, чем больше приходится сталкиваться с постманом и подобными поделками, тем больше жалею, что забросил в далёком 2009 писать GUI для libcurl аж на RealBASIC. Функциональности было столько же, летало как нативное, только вот со временем проще стало запоминать команды, чем поддерживать эту жесть. Но как минимум оно умещалось в пару мегабайт оперативки, чего для её задачи в принципе-то всё ещё слишком много.
Имхо нативные приложения для десктопа на чём бы то ни было приятнее и использовать, и разрабатывать, и распространять.
По поводу электрона — разработка под веб значительно сложнее, чем под десктоп, будь то даже Qt на С++. И инструменты под веб относительно не очень. Потому годится электрон только для таких кейсов как у Вас, когда в команде большой экспириенс в js, и мало в других языках.
По поводу электрона — разработка под веб значительно сложнее, чем под десктоп, будь то даже Qt на С++. И инструменты под веб относительно не очень. Потому годится электрон только для таких кейсов как у Вас, когда в команде большой экспириенс в js, и мало в других языках.
В представленных примерах приложение на электроне либо опенсорсное, либо бесплатное (иногда есть отдельные платные фичи завязанные на внешний сервис). Ни слова о том, как у Electron обстоят дела с обфускацией кода и защитой от отладки, что весьма интересно для приложения на котором хочется делать бизнес.
Основная проблема приложений на Electron — это не только невероятное количество потребляемых ресурсов, но и отзывчивость интерфейса. И вот это уже ставит крест на вашем приложении.
Потому что многие разработчики критичны к этому параметру, и не будут в качестве рабочего инструмента использовать что-то тормозящее.
Я так и не понял, чем вас не устроила связка Qt/C++. Почему упор на C#?
Electron обычно используется по причине дешевизны разработки — потому что высокая степень унификации между веб-версией и десктоп-версией в плане кода. Но у вас такой проблемы не стояло — и выбор от этого «браузера в окне десктопного приложения» выглядит ещё более странным.
Потому спасибо, но нет.
Потому что многие разработчики критичны к этому параметру, и не будут в качестве рабочего инструмента использовать что-то тормозящее.
Я так и не понял, чем вас не устроила связка Qt/C++. Почему упор на C#?
Electron обычно используется по причине дешевизны разработки — потому что высокая степень унификации между веб-версией и десктоп-версией в плане кода. Но у вас такой проблемы не стояло — и выбор от этого «браузера в окне десктопного приложения» выглядит ещё более странным.
Потому спасибо, но нет.
Почему вы выбрали electron?
Потому что ничего не знали про wx, например.
Wxnode, если хотите JavaScript.
Его, кажется, только под c# кросс-платформенный нет. Технологии (платформе?) более 20 лет, и она поддерживается и развивается. Думаю, даже когда JavaScript станет многопоточным и в нём запретят 1+'1' и подобное, wx будет развиваться.
Самая первая фраза в readme репозитория
Feel free to use this module but, I am no longer supporting it in favor of AppJs
Ну и последний коммит 7 лет назад.
Feel free to use this module but, I am no longer supporting it in favor of AppJs
Ну и последний коммит 7 лет назад.
НЛО прилетело и опубликовало эту надпись здесь
Ой.
А мой код из нескольких проектов написаный на С# работает на Linux, MacOs, iOs и Android.
Что я делаю не так?
А мой код из нескольких проектов написаный на С# работает на Linux, MacOs, iOs и Android.
Что я делаю не так?
НЛО прилетело и опубликовало эту надпись здесь
Для webAPI и console app использую .NET Core.
Причем вне зависимости винда или линукс — мне .NET Core симпатичнее, чем виндовый .NET Framework, потому что работает быстрее, опенсорсный и многие штуки там сделаны уже проще чем в старом .NET.
На MacOS он тоже будет работать.
iOS и Android — на Xamarin. Его же можно использовать для UWP-приложений и запускать в винде, но я не делал такого.
Разработка при работе на винде — VS 2017, на маках — VS 2017 for MAC, разок надо было под убунтой девелопить — тут VS Code использовал. VS 2017 можно использовать Community edition — она для индивидуального разработчика дает фактически все тоже самое что и платные версии.
Причем вне зависимости винда или линукс — мне .NET Core симпатичнее, чем виндовый .NET Framework, потому что работает быстрее, опенсорсный и многие штуки там сделаны уже проще чем в старом .NET.
На MacOS он тоже будет работать.
iOS и Android — на Xamarin. Его же можно использовать для UWP-приложений и запускать в винде, но я не делал такого.
Разработка при работе на винде — VS 2017, на маках — VS 2017 for MAC, разок надо было под убунтой девелопить — тут VS Code использовал. VS 2017 можно использовать Community edition — она для индивидуального разработчика дает фактически все тоже самое что и платные версии.
НЛО прилетело и опубликовало эту надпись здесь
я писал ответ на
"
«c# кросс-платформенный»
Слово «кроссплатформенный» нельзя применять к различиям между Windows 7 и Windows 10, как делает Microsoft в своих рекламных материалах."
На языке C# я могу писать под разные OS и оно будет работать, но да — пока нельзя писать десктоп под Линукс и Мак.
Будем ждать WPF — она пока перебирается на .NET Core и может уже потом под нее сделают движки для Linux и Mac. После перевода на .NET Core и открытия всего кода это будет уже значительно проще
"
«c# кросс-платформенный»
Слово «кроссплатформенный» нельзя применять к различиям между Windows 7 и Windows 10, как делает Microsoft в своих рекламных материалах."
На языке C# я могу писать под разные OS и оно будет работать, но да — пока нельзя писать десктоп под Линукс и Мак.
Будем ждать WPF — она пока перебирается на .NET Core и может уже потом под нее сделают движки для Linux и Mac. После перевода на .NET Core и открытия всего кода это будет уже значительно проще
НЛО прилетело и опубликовало эту надпись здесь
«WPF перебирается на .NET Core » — это не правда, ничего подобного и близко нет. Загуглите что означает буква W в аббревиатуре WPF. Посмотрите как она устроена внутри. Посмотрите, когда вышел последний релиз. Эту библиотеку закапывать пора, а не портировать на линукс.
Скорее всего, имелся ввиду .NET core, а не mono.
Не для полемики, а из любопытства: а Xamarin + Xamarin.Mac чем не устроили?
Я почему спрашиваю… Я бы такую задачу решал на Delphi, но это чисто личный выбор. У меня команда вся на Delphi пишет, куча отлаженного кода и нужных классов, большой опыт разработки на Delphi для Win и Mac. Но если бы я был не я, а какой-нибудь более молодой человек, без «наследства», который может выбрать любой инструмент чтобы начать проект с чистого листа? Я никогда не пользовался Xamarin + Xamarin.Mac, но из того, что я слышал, вроде бы это то что надо, и не нужен никакой Electron с большим RAM usage и противненьким ненативным рендерингом шрифтов? Или я что-то упускаю?
Я почему спрашиваю… Я бы такую задачу решал на Delphi, но это чисто личный выбор. У меня команда вся на Delphi пишет, куча отлаженного кода и нужных классов, большой опыт разработки на Delphi для Win и Mac. Но если бы я был не я, а какой-нибудь более молодой человек, без «наследства», который может выбрать любой инструмент чтобы начать проект с чистого листа? Я никогда не пользовался Xamarin + Xamarin.Mac, но из того, что я слышал, вроде бы это то что надо, и не нужен никакой Electron с большим RAM usage и противненьким ненативным рендерингом шрифтов? Или я что-то упускаю?
Ну во-первых его нет для linux. И он бы нас не устроил уж очень малым набором готовых компонентов. К примеру, тот же самой редактор с подсветкой синтаксиса самим писать не хотелось.
Ок, спасибо. Не знал про малый выбор компонентов.
Думаю, что Lazarus в этом смысле был бы лучше. Умеет в том числе в Линукс, Мак, Малину. Редактор с подсветкой синтаксиса точно есть. Собственно — сам Лазарус, который полностью в сырцах. Там же можно посмотреть как и что сделано. Подсветка, дополнение кода и прочее. Бесплатный, без жуткого оверхида по памяти и скорости. Всё нативное:
НЛО прилетело и опубликовало эту надпись здесь
нужно бросать на формуНе обязательно. Существуют специальные дата модули (TDataModule). На них кидать удобнее.
И ещё в глаза бросилось, что в последнем примере автор не знает про anchors. Типичная болезнь делфистов никуда не делась. Уж лучше бы, наверное, в Лазарусе были layouts.Всё это есть. Просто не поставлено. Есть разные сборки, как на первых скринах, так и как на последнем. Некоторые сборки идут сразу со связанными окнами в рабочий стол, некоторые — как на последнем скрине. Но можно доставить пакет из списка доступных в несколько кликов, будет выглядеть связанным. Lazarus/FPC, в отличие от Делфи, полностью оупенсорсный и его коробочных сборок существует штук 5. Можно выбрать более удобную.
НЛО прилетело и опубликовало эту надпись здесь
А, ну это же тестовая наброска :) По умолчанию там Align = alNone, поставите, например, alBottom и будет как хочется. Среда сама за программера не додумывает, как ему удобнее якоря сделать. Layouts мне не нравится отсутствием wysiwyg. Не сразу ясно, что получим на выходе, запускать приходится. Ну или мне такие layouts попались.
Пробежался — не нашел компонентов-редактров для подсветки синтаксиса с автодоподнением и поддержкой подсветки js, json, xml, yaml и возможно ещё чего нибудь. Ну вот не нашел я компонентов уровня ace editor или code mirror. Нативные компоненты 1) мне не нравятся, 2) выглядят по разному на разных ос, что усложняет поддержку. Кастомизация интерфейса очень неудобная по сравнению со связкой HTML и css.
Можете посмотреть 'коробочный' TSynEdit:
Нативные компоненты 1) мне не нравятся, 2) выглядят по разному на разных ос, что усложняет поддержкуПодавляющему большинству (мне в том числе) нравятся нативные компоненты. По поводу поддержки уже сказали. Что не стоит проблемы разработчиков перекладывать на плечи пользователей.
Вот пара примеров TSynEdit'а:
Поискал, нашел такой проект (Delphi):
www.windows8downloads.com/win8-dev-php-pujtiyff/screenshot.html
Исходники:
devphp.sourceforge.net
Поискал, нашел такой проект (Delphi):
www.windows8downloads.com/win8-dev-php-pujtiyff/screenshot.html
Исходники:
devphp.sourceforge.net
Одной рукой ругаем скайп (с точки зрения пользователя), а с другой пишем сами на электроне потому что *куча_причин_почему_электрон_лучше*.
Может не совсем в тему, прошу прощения.
Есть приложение на Electron — стоит задача часть кода оставить в web, часть перенести на сервер.
Вопрос спецам — стоит ли этой фигней заниматься?
Есть приложение на Electron — стоит задача часть кода оставить в web, часть перенести на сервер.
Вопрос спецам — стоит ли этой фигней заниматься?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мы выбрали Electron