Comments 119
1) Возможность создавать сценарии запросов (создать сущность -> получить сущность чтобы проверить, что она существует -> удалить сущность)
2) Создания тестов без программирования. Мы имеем конструктор assertion-ов, который позволяет создавать их из UI. В случае сложных тестов вы так же можете написать скриптовый assertion на javascript.
3) Человекочитаемый формат проектов (базирующийся на yaml). Это позволяет синхронизировать проект через системы контроля версий с возможностью code-review и т.д.
4) Автокомплит переменных, заголовков, протоколов и т.д.
Жду от вас статью уже для тестировщиков, где вы наверное расскажите про этот пункт и п.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
Русскую версию выложим тут в течении недели наверное.
Перепроверил — вы правы. Тогда — только AvaloniaUI.
Например window.open работает с другим API, и даже если сделать nativeWindowOpen он не будет полноценно работать
В случае использования авторизации через фейсбук, у открываемого окна не будет доступен window.opener, что ставит крест на возможности авторизации(хотя для electron@2 есть воркэраунд)
Других значимых отличий по части браузерной работы я за полгода пока не нашел
А Electron, позволяя разработчику «перенести наработки из web почти без изменений», непомерно и неоправданно жрёт ресурсы конечного потребителя. Именно из-за таких парадигм мы и не имеем в конечной производительности информационных систем того экспоненциального роста, который демонстрируют формальные показатели (а-ля закон Мура)!
На данный момент многие популярные приложения написаны на Electron
Не использую ни одно из перечисленных приложений именно из-за того, что они на Electron. Мне, знаете ли, «по долгу службы» нужно держать две виртуалки, немаленькую базу данных, поисковый движок с индексом этой базы и одновременно с этим как-то позволять себе котиков на ютубе посмотреть и в кс пострелять. А два-три работающих Electron-приложения могут почти переплюнуть это всё по потреблению памяти. Спасибо, не надо.
Давно мечтаю о нативном аналоге Postman.
Для стартапа это на мой взгляд непозволительно.
И, к счастью, их на electron ещё не переписали, и надеюсь, не станут никогда.
Они сравнимы вполне по потреблению ресурсов с разными Nеtbeans и Eclipse которые их конкуренты потенциальные.
А вот Atom или VSCode уже можно посравнивать с нативными редакторами, и они явно проигрываеют им по потреблению ресурсов. И пользуются, как раз, в этой нише, не только ими, и даже не в основном ими в итоге хоть они и довольно популярны…
VSCode, увы, не является IDE. "Integrated" из аббревиатуры не хватает. Все расширения живут своей жизнью и общаются с вскодом по LSP. В такой ситуации сделать расширение, которому, скажем, нужна из OmniSharp информация о проектах в солюшене, просто напросто невозможно. Это, кстати, одна из причин, по которым у Avalonia до сих пор нет расширения под вскод, нужно самостоятельно парсить солюшен, самостоятельно пинать мсбилд, итп.
а) имеет latency до нескольких сотен (тысяч?) милисекунд в те моменты, когда этого хочется v8
б) ест память так, как будто оно запущено на тьюринг-машине с бесконечной лентой
в) заедает процессором.
Чем больше пользователи будут его использовать, тем более негативным будет их опыт. При этом пути назад почти не будет, потому что в разработку вложено много сил.
задержек нет даже когда я активно набираю
Другие пользователи с вами почему-то не согласны 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 с примерно одинаковой частотой. Технологии диаметрально противополжные — проблема одна.
Ну то есть кривая реализация.
Нативные CSS-анимации — кривая, а setInterval — не кривая? Весело.
Замечу, что фризы возникают и в Visual Studio и в Jetbrains и в VS Code с примерно одинаковой частотой.
Поэтому я сижу на Sublime ;)
Ну и надо признать, что веб технологии с реактами, редаксами, npm-ами, css-ом вот этим всем выглядят просто чудовищно уродливо в сравнении с популярными нативными фреймворками для десктопных gui приложений
Обертка для веб-сайтов имеет свою узкую нишу применения. Не надо его использовать везде. Да тот же скайп как пример. Нативное приложение ресурсы не ело и было отзывчивым и удобным. Как только запихнули в электрон, так пользоваться стало жутко неудобно. Пришлось отказаться.
Почему мы выбрали электрон?
Здравствуйте.
Дешевле.
Спасибо за внимание.
Аргумент веский, но КМК подходит не для всех приложений. Для обычных пользователей может и зайдет — они не разбираются электрон это или не электрон. Для разработчиков/админов и.т.д. только если приложение предоставит им больше возможностей чем конкуренты.
Как-то обсуждали электрон и сошлись во мнении что: «За деньги я вам напишу что угодно и на чем угодно, но сам использовать не буду».
Так, мысли вслух.
Всё нативное, само собой.
Лазарус, если что, полностью бесплатный. Delphi бесплатный с ограничениями по доходам.
Ну и в завершении по поводу дешевизны разработки на Delphi/Lazarus. Зашел на сервис зарплат в моем круге (лучше, извините, ничего не придумал) чтобы оценить во сколько раз отличается количество delphi и js разработчиков. Delphi — 24 разработчика, js — 9147 разработчика. Разница просто колоссальная и она в целом отражает ситуацию на рынке — на js найти разработчика проще, чем на delphi, я думаю вы спорить не будете. Ну а между проще и девешле фактически можно ставить знак равенства.
В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.
В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.По собственному опыту. Выхлоп отличного Delphi программиста против выхлопа отличного JS. Зарплата получается примерно одинаковая, но отдача не сопоставима, увы.
Людей найти можно и тех и других.
Большинство из того, что вы перечислили скорее всего есть в виде готовых Delphi компонент. Собственно — сама Delphi (IDE) написана на Delphi.
Каждое приложение на electron потребляет какое-то совершенно невероятное количество ресурсов: оперативной памяти и процессорного времени, что никак не коррелирует со сложностью и функциональностью приложения. Каждое приложение на электроне тормозит и фризится даже на мощных рабочих станциях. Даже хвалёный тут и везде vscode. Одно, второе, третье приложение на электроне и вот уже мощная рабочая станция превращается в тыкву… гори в аду, electron!
А PWA это все те же js+html+css.
«PWA это все те же js+html+css» — что означает все те же проблемы что и с вебом в виде зависимости от js (ибо даже при транспиляции именно js будет в итоге), тормозов (несмотря на jit'ы)
И чем же PWA — ужас и боль?Яндекс.Избач (дополнение для Яндекс.Метрики) — не только мониторит действия пользователей на сайте, но и вероломно шарится в их компьютерах. Ура! (надеюсь шутка).
C#, TypeScript, Go
Могу я узнать, почему вы не смотрели в сторону jvm?
… на сегодняшний день… (с поправкой в том числе и на количество доступных специалистов на рынке)… и OpenJFX ..
Я, конечно, практически не изучал данный вопрос, но разве по FX есть достаточное количество вакансий\проектов\специалистов? Да даже хотя бы обширное коммьюнити с достаточным количеством мануалов и гайдов?
Чисто по внешнему впечатлению, развитие этого продукта остановилось, им никто не интересуется, статьи о нём не пишутся на тот же хабр. Не слышал о нём за последние два года ни разу, вот от вас только, хотя постоянно слежу за общим фоном Java-мира.
Пробовал изучать FX и просто по удобству использования использования и удобству разработки сравнивал с шарповыми WinForm\WPF, которые под mono спокойно запускались на линуксах в том числе. Сравнивал чисто в пользовательском смысле.
И, FX безумно проигрывал по скорости разработки и удобству. Безумное количество лишних действий, которые не удобны в том числе из SceneBuilder. И сам SceneBuilder тормознутое, топорное и чудное… было пару лет назад.
Я, разумеется, его не правильно готовил, с этим спорить не приходится, тем не менее — общее состояние дел как-то изменилась за эти два года или всё примерно на том же уровне? Использовал FX-8
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть. Как и везде. SceneBuilder я не использовал. Сейчас вообще десктоп инструменты используются значительно реже. Я также использую данный фреймворк лишь эпизодически. Хотя и давно. Как он может безумно (!) проигрывать хоть чему-то, мне не понять. Обычно так эмоционально выражаются апологеты другой платформы (скажем .NET), знакомые с Java инструментами крайне поверхностно, но изначально идеологически настроенные против.
Из своего опыта, могу сказать, что некоторое отчуждение испытывали люди, которые впервые сталкивались с более новой концепцией построения GUI. JavaFX использует некий базовый контейнер-подмосток, на котором может быть выстроена одна иди несколько сцен, состоящих из любых графических элементов. Каждую сцену, вместе со всем её содержимым, можно как угодно трансформировать (масштабировать, скручивать, поворачивать...), анимировать, менять цвета и яркости. И даже источники света размещать. Некая форма с кнопками это всего лишь частный случай сцены. А в целом получается очень гибкая графическая конструкция (и 3D). Идея не нова, таким же образом построены Qt и WPF. Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным. К чему такая мощь для кнопочек? Ну только лишь для кнопочек может и ни к чему.
Ещё одна не всем привычная и пугающая новичков фишка — реактивность свойств. Любое свойство графического объекта может быть «сцеплено» с другим свойством другого объекта. То, в свою очередь, с неким свойством третьего и так далее. Меняя одно свойство, автоматически меняются связанные. Примерно как пересчитываются связанные клетки в Excel. Ну и сцена обновляется. Идея не нова, она положена в основу реактивного программирования, но если вы не имеете навыков такого рода построения интерфейса, то… вы опять же сразу не оцените всю мощь и гибкость такого подхода. И будете по привычке искать какие-нибудь события для того, что бы их «как обычно» обработать.
Есть ещё одна особенность, которую некоторое количество людей люто, патологически ненавидят. JavaFX — фреймворк класса 'lightweight'. Другими словами — все свои контролы он рисует сам и не использует родные контролы операционной среды. Ну и стало быть интерфейс может выглядеть не как родной, нейтивный. Также устроен и Qt. И старенький Swing.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть.
Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным
Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.
Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.
Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.
По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
Qt пошла по рукам. JavaFX стагнирует. Javascript возомнил себя победителем, и теперь все новые проекты это чисто Франкенштейны типа Электрона. Цивилизация куда-то не туда свернула, пытается выкарабкаться всякими там TypeScript…
Оно может и неплохо, что FX ушла в Open мир. :)
По поводу электрона — разработка под веб значительно сложнее, чем под десктоп, будь то даже Qt на С++. И инструменты под веб относительно не очень. Потому годится электрон только для таких кейсов как у Вас, когда в команде большой экспириенс в js, и мало в других языках.
Потому что многие разработчики критичны к этому параметру, и не будут в качестве рабочего инструмента использовать что-то тормозящее.
Я так и не понял, чем вас не устроила связка Qt/C++. Почему упор на C#?
Electron обычно используется по причине дешевизны разработки — потому что высокая степень унификации между веб-версией и десктоп-версией в плане кода. Но у вас такой проблемы не стояло — и выбор от этого «браузера в окне десктопного приложения» выглядит ещё более странным.
Потому спасибо, но нет.
Почему вы выбрали electron?
Потому что ничего не знали про wx, например.
Wxnode, если хотите JavaScript.
Его, кажется, только под c# кросс-платформенный нет. Технологии (платформе?) более 20 лет, и она поддерживается и развивается. Думаю, даже когда JavaScript станет многопоточным и в нём запретят 1+'1' и подобное, wx будет развиваться.
Feel free to use this module but, I am no longer supporting it in favor of AppJs
Ну и последний коммит 7 лет назад.
А мой код из нескольких проектов написаный на С# работает на Linux, MacOs, iOs и Android.
Что я делаю не так?
Причем вне зависимости винда или линукс — мне .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 и открытия всего кода это будет уже значительно проще
Я почему спрашиваю… Я бы такую задачу решал на Delphi, но это чисто личный выбор. У меня команда вся на Delphi пишет, куча отлаженного кода и нужных классов, большой опыт разработки на Delphi для Win и Mac. Но если бы я был не я, а какой-нибудь более молодой человек, без «наследства», который может выбрать любой инструмент чтобы начать проект с чистого листа? Я никогда не пользовался Xamarin + Xamarin.Mac, но из того, что я слышал, вроде бы это то что надо, и не нужен никакой Electron с большим RAM usage и противненьким ненативным рендерингом шрифтов? Или я что-то упускаю?
нужно бросать на формуНе обязательно. Существуют специальные дата модули (TDataModule). На них кидать удобнее.
И ещё в глаза бросилось, что в последнем примере автор не знает про anchors. Типичная болезнь делфистов никуда не делась. Уж лучше бы, наверное, в Лазарусе были layouts.Всё это есть. Просто не поставлено. Есть разные сборки, как на первых скринах, так и как на последнем. Некоторые сборки идут сразу со связанными окнами в рабочий стол, некоторые — как на последнем скрине. Но можно доставить пакет из списка доступных в несколько кликов, будет выглядеть связанным. Lazarus/FPC, в отличие от Делфи, полностью оупенсорсный и его коробочных сборок существует штук 5. Можно выбрать более удобную.
Пробежался — не нашел компонентов-редактров для подсветки синтаксиса с автодоподнением и поддержкой подсветки js, json, xml, yaml и возможно ещё чего нибудь. Ну вот не нашел я компонентов уровня ace editor или code mirror. Нативные компоненты 1) мне не нравятся, 2) выглядят по разному на разных ос, что усложняет поддержку. Кастомизация интерфейса очень неудобная по сравнению со связкой HTML и css.
Нативные компоненты 1) мне не нравятся, 2) выглядят по разному на разных ос, что усложняет поддержкуПодавляющему большинству (мне в том числе) нравятся нативные компоненты. По поводу поддержки уже сказали. Что не стоит проблемы разработчиков перекладывать на плечи пользователей.
Поискал, нашел такой проект (Delphi):
www.windows8downloads.com/win8-dev-php-pujtiyff/screenshot.html
Исходники:
devphp.sourceforge.net
Есть приложение на Electron — стоит задача часть кода оставить в web, часть перенести на сервер.
Вопрос спецам — стоит ли этой фигней заниматься?
Почему мы выбрали Electron