Предыстория
Мы небольшая команда разработчиков, занимаемся созданием нового инструмента для работы с API Testmace. По факту это продвинутый rest клиент с возможностью создавать автоматизированные тесты API с помощью графического интерфейса, оснащенный такими приятными штуками как продвинутый механизм переменных, автокомплит во всех полях ввода и тотальная подсветка синтаксиса.
Хочу вам рассказать о том, как мы пришли к Electron как технологии для написания нашего приложения.
Почему десктоп
В последние 10-15 лет web пережил взрывной рост и продолжает активно развиваться. Постоянно появляются все новые и новые инструменты для создания все более функциональных и сложных web-приложений. Создаются даже целые языки программирования, заточенные для написания web-приложений и практически не имеющие готовых решений вне этой области. Да и в нашей повседневной жизни мы уже частично заменили microsoft office и thunderbird на google docs и интерфейс gmail-а.
Однако веб не может пока полностью вытеснить десктопные приложения, и вот по каким причинам:
- Недостаточная отзывчивость web-приложений. Где-то всему виной клиент-серверная синхронизация и медленный интернет, где-то однопоточная природа javascript-а, а где-то и просто прожорливость браузера на вашей не очень мощной машине. Стоит заметить, что решение вышеперечисленных проблем лишь вопрос времени. В частности, web worker-ы уже поддерживаются всеми современными браузерами, что частично решает проблему отсутствия многопоточности, а возможности типа SharedArrayBuffer позволяют уменьшить накладные расходы на копирование памяти между основным потоком и воркерами.
- Доступ к локальным ресурсам системы. Есть целые классы приложений (файловые менеджеры, tweaker-ы, демоны и сервисы) которые не могут быть реализованы как web-приложения (по крайней мере на данном этапе развития).
- Ограничения возможностей самого браузера. К примеру, сетевое взаимодействие ограничивается только отправкой http запроса и соединения по web-socket-ам. Более низкоуровневые вещи (tcp, upd сокеты), увы, недоступны.
- Искусственные ограничения браузеров в целях безопасности. CORS, работа с cookies, ограничения на отсылаемые заголовки.
- Ограниченный набор языков и подходов. В отличие от web-приложений, где единственным языком для написания приложений остается javascript, десктопные приложения позволяют использовать любые языки программирования вплоть до ассемблеров, эффективно использовать ресурсы системы, применяя многопоточное программирование и низкоуровневые инструкции. Стоит отметить, что по данному вопросу ситуация улучшается — появляются транспилеры из некоторых языков в javascript. Более того, компиляция в webassembly позволяет перенести наработки из других языков (C++, C#, rust и т.д.), зачастую получая неплохой прирост производительности.
Рассматривая причины, перечисленные выше, мы можем прийти к выводу, что TestMace должен быть типичным десктопным приложением:
- Нам необходим доступ к файловой системе для работы с проектом.
- Ограничения fetch не позволяют получить полный контроль над конфигурированием и выполнением запроса.
- В будущем нам могут потребоваться низкоуровневые оптимизации для улучшения производительности приложения.
Выбор технологии
Мы определились, что наше приложение будет десктопным, однако, пока не определились с языком и технологиями, на которых будем это реализовывать. Что касается языков программирования, то к ним нами предъявляются следующие требования:
- Это должен быть язык со статической типизацией.
- Язык должен иметь большую и зрелую инфраструктуру — должны быть как проверенные библиотеки так и поддержка со стороны IDE и других инструментов.
- Язык должен быть знаком большинству членов команды.
Последний пункт также немаловажен. Мы как стартап заинтересованы в скорейшем (в течении полугода) выводе продукта на рынок, максимально используя внутренние ресурсы команды. Изучение нового языка и инфраструктуры уменьшает предсказуемость планирования и чревато ошибками в принятии тех или иных решений.
Как бы то ни было, список требований не кажется уж слишком жестким, и ему удовлетворяют такие языки как C#, TypeScript, Go. Дальнейший выбор технологий будем проводить с учетом наличия реализаций необходимых компонентов для данных языков.
Гораздо более интересно обстоят дела с выбором решений для разработки пользовательского интерфейса. Требования к ним следующие:
- Кроссплатформенность (Windows, Linux, MacOS)
- Богатый набор как встроенных так и сторонних компонентов
- Кастомизируемость компонентов
- Наличие языка разметки для описания интерфейса
- Хорошая поддержка
Рассмотрим, какие решения подходят под данные требования.
Qt (Qml)
Qt — это мощный тулкит для написания кроссплатформенных приложений. В последних версиях данного фреймворка появился компонент Qt Quick для написания приложений с использованием декларативного языка описания разметки QML. Qt в общем и QML в частности — это проверенные в боях решения, нашедшие свое применение практически во всех сферах — от embedded до программных оболочек операционных систем.
Основным языком программирования в Qt является C++ (в QML можно использовать javascript). Однако для Qt и QML есть биндинги для других языков программирования (вот например для C#). Однако официально поддерживается только интеграция с питоном. Все остальное — сторонние реализации. Согласитесь, не хотелось бы доверять самую базовую часть приложения библиотеке, которую разрабатывает как хобби небольшая группа энтузиастов.
Еще есть проект Brig. Это NodeJS биндинги для QML. Отличительной особенностью данного проекта является впечатляющая демка. Однако, как оно часто бывает в open source проектах, авторы не уделяют должного внимания проекту и поэтому он также сходит с дистанции.
GTK
Библиотека для построения пользовательского интерфейса, которая начиналась как часть проекта GIMP и впоследствии была выделена в отдельный проект. Имеется инструмент Glade для быстрой разработки пользовательского интерфейса. Основным языком для разработки GTK является C, однако есть биндинги для многих популярных языков программирования. Более того, с использованием C# биндингов создавалась MonoDevelop — одна из самых мощных IDE для разработки под C#. Однако после более внимательного изучения мы понимаем, что проект GTK# находится в полузаброшенном состоянии — последний коммит был в феврале 2018, следующий в январе 2017 и далее 2016. По коммиту в год. Негусто, учитывая, что основной репозиторий gtk активно развивается. А счастье было так близко…
Electron
В последнее время очень много шума связано с данным фреймворком. Кто-то хвалит его за возможность перенести наработки веб-приложений на десктоп, кто-то ненавидит за чрезмерную прожорливость. И тех и других можно понять. Electron под капотом использует node.js и библиотеку рендеринга из Chromium. По сути создается обычное web-приложение и заворачивается в исполняемый файл. Причем каждое приложение поставляется с собственной версией Node.js и Chrome.
Минус по сути только один, но достаточно серьезный — это большое (по сравнению с другими технологиями) потребление памяти: пустой проект занимает в памяти 100-200 мегабайт. Для некоторых это причина отказаться от использования таких приложений (привет, Skype). Однако давайте проанализируем ситуацию на рынке. На данный момент многие популярные приложения написаны на Electron (Slack, Skype, Discord, VSCode, Atom, Postman, Insomnia и т.д.). Многие из них являются стандартами в своей сфере или стремительно завоевывают сердца пользователей (как, например, те же VSCode и Insomnia). Люди просто используют инструменты, которые хорошо решают их повседневные задачи, невзирая на некоторые побочные эффекты. С другой стороны, компьютеры становятся все мощнее (как минимум, рост RAM не прекратился), и все меньше приходится слышать отзывы недовольных клиентов, что «ваш хром съел всю мою память». Резюмируя, мы считаем, что повышенное потребление оперативной памяти не будет играть большой роли в случае, если продукт будет действительно хорош в своей сфере.
Плюсы же данной технологии очевидны:
- Возможность использования наработок из web.
- Проще найти специалистов в данной сфере.
- Отработанный воркфлоу «дизайнер» — «верстальщик» — «программист», изобилующий удобными инструментами на каждом этапе.
Также к плюсу мы относим тот факт, что команда имеет большой опыт создания front-end приложений.
В итоге, мы остановились на Electron как на основном инструменте для разработки нашего проекта. Автоматически, в качестве языка для разработки приложения мы выбрали TypeScript.
Заключение
Одна из основных задач стартапа — это скорейший вывод продукта на рынок. Круто, если получится это сделать с минимальными затратами. Целью данного анализа и было найти такой инструмент, который позволил бы нам решить эти задачи. На наш взгляд, Electron прекрасно нам подходит. Спустя три месяца после начала разработки, он до сих пор вне конкуренции, и, похоже, у нас все серьезно.
Комментарии (102)
imanushin
12.02.2019 16:49А вы не рассматривали WPF или WinForms для .Net Core? Они кроссплатформенные, едят намного меньше ресурсов. Плюс у них есть честная многопоточность, немало библиотек и т.д.
dimansny Автор
12.02.2019 16:55Судя по github.com/dotnet/wpf/issues/48#issuecomment-444198305 оно не очень кроссплатформенное и вроде даже не собирается. Насчет остального тоже, многопоточность вполне честная, пусть и не такая удобная как в C#, да и коммьюнити у js достаточно мощное и готовых решений хватает
dimansny Автор
12.02.2019 16:57Когда говорят о кроссплатформенности на .NET всегда упомянают AvaloniaUI, однако она в бете
mxmvshnvsk
12.02.2019 16:56+2Было бы интересно прочитать продолжение статьи через 6-8 месяцев активной разработки, когда будут уже сформированные процессы, возможно какие-то метрики и относительно большой опыт командной разработки. Тогда можно было подробно написать про объективные плюсы и муинусы.
dimansny Автор
12.02.2019 17:00Прелесть Electron состоит в том, что можно перенести наработки (как функциональные, так и с точки зрения бизнес-процессов) из web почти без изменений. Поэтому я думаю, что electron в этом плане нам палки в колеса вставлять не будет.
Alternator
14.02.2019 18:16Хотя кажется что все что работает в браузере(Chrome), будет работать и в electron — это не совсем так.
Например window.open работает с другим API, и даже если сделать nativeWindowOpen он не будет полноценно работать
В случае использования авторизации через фейсбук, у открываемого окна не будет доступен window.opener, что ставит крест на возможности авторизации(хотя для electron@2 есть воркэраунд)
Других значимых отличий по части браузерной работы я за полгода пока не нашел
andreymal
12.02.2019 17:01+5На данный момент многие популярные приложения написаны на Electron
Не использую ни одно из перечисленных приложений именно из-за того, что они на Electron. Мне, знаете ли, «по долгу службы» нужно держать две виртуалки, немаленькую базу данных, поисковый движок с индексом этой базы и одновременно с этим как-то позволять себе котиков на ютубе посмотреть и в кс пострелять. А два-три работающих Electron-приложения могут почти переплюнуть это всё по потреблению памяти. Спасибо, не надо.
Давно мечтаю о нативном аналоге Postman.
dimansny Автор
12.02.2019 17:08Отчасти согласен, что самой большой претензией является сравнительно большое потребление памяти. Но. Смею заметить, что та же insomnia или постман потребляют в районе 500 МБ оперативной памяти. Для людей, который активно используют подобного рода инструменты подобные показатели — копейки. Зато функционал с лихвой перекрывает данный недостаток. Возможно в вашем случае этот функционал не критичен и вам достаточно того же curl
Anastasia_K
12.02.2019 17:55+4такое потребление это фейл. Определённые приложения могут возложить МПХ на своих пользователей в силу своей уникальности, что конечно же не делает им чести. Как правило это либо приложения, ставшие популярными в веб-версии, и выпустившие _такой_ клиент в качестве бонуса, либо приложения, уже имеющие огромную аудиторию, и перешедшие на электрон при очередном обновлении. Люди в силу инертности, привычки и базы контактов будут терпеть.
Для стартапа это на мой взгляд непозволительно.dimansny Автор
12.02.2019 18:15Тут я с вами не согласен. Ну начнем про стартап. Electron очень хорошо подходит для быстрого старта (большое количество специалистов, компонентов, текущие компетенции команды) — самое то для стартапа. Во-вторых, про то, что пользователи «терпят» — опыт атома, vs code, git kraken говорят об обратном, сообщества растут и развиваются. Да и найдите приложение, которое сфейлилось исключительно от большого потребления памяти? Что-то не припомню. Гораздо важнее, чтобы инструмент решал повседневные задачи пользователей. И, по моему скромному мнению, если инструмент успешно справляется с поставленными задачами по сравнению с конкурентами, то некоторую прожорливость (некатастрофическую) ему простят. Вы же не променяете IDE от Jetbrains на Notepad++ только из-за памяти, правда?
kotomyava
12.02.2019 22:43IDE от Jetbrains, это совершенно другой весовой категории приложения.
И, к счастью, их на electron ещё не переписали, и надеюсь, не станут никогда.
Они сравнимы вполне по потреблению ресурсов с разными Nеtbeans и Eclipse которые их конкуренты потенциальные.
А вот Atom или VSCode уже можно посравнивать с нативными редакторами, и они явно проигрываеют им по потреблению ресурсов. И пользуются, как раз, в этой нише, не только ими, и даже не в основном ими в итоге хоть они и довольно популярны…dimansny Автор
13.02.2019 00:04-1А почему бы не сравнить тот же VSCode с Eclipse или Netbeans? У VSCode есть все фишки IDE.
kekekeks
13.02.2019 08:56VSCode, увы, не является IDE. "Integrated" из аббревиатуры не хватает. Все расширения живут своей жизнью и общаются с вскодом по LSP. В такой ситуации сделать расширение, которому, скажем, нужна из OmniSharp информация о проектах в солюшене, просто напросто невозможно. Это, кстати, одна из причин, по которым у Avalonia до сих пор нет расширения под вскод, нужно самостоятельно парсить солюшен, самостоятельно пинать мсбилд, итп.
vladkorotnev
13.02.2019 03:42В итоге как всегда tl;dr: мы выбрали электрон, потому что так тупо дешевле.
Alex_Crack
12.02.2019 22:23Попробуйте SoapUI. Не совсем нативное (java), но по сравнению с postman'ом он гибче и имеет намного больше возможностей.
amarao
12.02.2019 17:17+9При том, что вы очень быстро оказываетесь на рынке, вы получаете колоссальный техдолг. Этот техдолг — ужасающее непредсказуемое урчащее. Как только ваше приложение начнёт использоваться по назначению (т.е. в работе), окажется, что оно:
а) имеет latency до нескольких сотен (тысяч?) милисекунд в те моменты, когда этого хочется v8
б) ест память так, как будто оно запущено на тьюринг-машине с бесконечной лентой
в) заедает процессором.
Чем больше пользователи будут его использовать, тем более негативным будет их опыт. При этом пути назад почти не будет, потому что в разработку вложено много сил.dimansny Автор
12.02.2019 17:26+2Ну уж вы сгустили краски). Тот же vs code — одна из самых популярных IDE на сегодняшний день — вполне себе шустро работает. Но то есть задержек нет даже когда я активно набираю и «требую» немедленного автокомплита) По поводу потребления процессора — тоже не вижу однозначной связи с electron. JS достаточно шустр. По поводу памяти нашу позицию я разъяснил в статье
andreymal
12.02.2019 18:07+5задержек нет даже когда я активно набираю
Другие пользователи с вами почему-то не согласны https://github.com/Microsoft/vscode/issues/27378
По поводу потребления процессора
А помните, когда-то давно мигающий курсор в VS Code кушал 13% процессора просто так?
dimansny Автор
12.02.2019 18:22+4А помните, когда-то давно мигающий курсор в VS Code кушал 13% процессора просто так?
Пробежался по статье. В конце нашел следующее
Но в конце концов разработчики из Microsoft всё-таки решили вернуться на старый добрый JS-метод setInterval для мерцания курсора — и потребление CPU сразу снизилось в несколько раз.
Ну то есть кривая реализация. Что поделать, всякое бывает, и не только на js.
Другие пользователи с вами почему-то не согласны github.com/Microsoft/vscode/issues/27378
Опять таки, исходя из этого всех собак надо повесить только на electron?) Замечу, что фризы возникают и в Visual Studio и в Jetbrains и в VS Code с примерно одинаковой частотой. Технологии диаметрально противополжные — проблема одна.andreymal
12.02.2019 18:23+3Ну то есть кривая реализация.
Нативные CSS-анимации — кривая, а setInterval — не кривая? Весело.
Замечу, что фризы возникают и в Visual Studio и в Jetbrains и в VS Code с примерно одинаковой частотой.
Поэтому я сижу на Sublime ;)
dimansny Автор
12.02.2019 18:40Поэтому я сижу на Sublime ;)
Возможно это выход, но явно не для каждого :)
dimansny Автор
12.02.2019 22:02Нативные CSS-анимации — кривая, а setInterval — не кривая? Весело
Ну и вы считаете, что на основе одного некритичного для многих и в конечном итоге решаемого бага вы делаете вывод о платформе в целом?) Не менее весело)
Groramar
12.02.2019 22:02+3Не очень сгустили. Пока Скайп был на Делфи, он нравился почти всем. Переписали на Электрон и он окончательно скатился в УГ (к моему большому сожалению, мне Скайп всегда нравился). У меня постоянные лаги и глюки на довольно хорошей машине (i7+gtx 960, 16 gb). На Андроиде Скайп работает просто отвратительно.
dimansny Автор
12.02.2019 22:06По поводу скайпа я с вами полностью согласен, совсем не радует во всех смыслах. Ну так и на скайпе мир клином не сошелся) В комментах упомянуты более интересные приложения на electron-е.
pawlo16
13.02.2019 18:46+1Однако же плохих приложений на электроне на много больше чем хороших. Сразу вспоминается Viber и пресловутая Слака. Да vscode изрядно фризится на механических винтах, не многим меньше jetbrains (если меньше).
Ну и надо признать, что веб технологии с реактами, редаксами, npm-ами, css-ом вот этим всем выглядят просто чудовищно уродливо в сравнении с популярными нативными фреймворками для десктопных gui приложений
numitus2
12.02.2019 17:26+7Глядя на повсеместное использование electron хочется спросить. Неужели современные интерфейсы настолько сложны, что использовать старые методы разработки нельзя. Не заметил чтобы интерфейс скайпа сильно посложнел. Однако раньше как то его реализовали на Delphi, а теперь нужен этот монстр.
dimansny Автор
12.02.2019 17:57Это вопрос интересный. У electron хорошая поддержка в лице web-инфраструктуры. Как следствие, большое разнообразие интерфейсных решений, отработанные процессы, потенциально большее количество специалистов, да и про кроссплатформенность не стоит забывать. Однако electron конечно не самоцель: если удобнее на Delphi — пишите на Delphi
elve
12.02.2019 19:50+3Обезьянки, выучившие пару глав учебника по JS это не специалисты. И то что из под них выходит использовать не хочется ну вот прям совсем. На данный момент вообще не использую приложения на электроне, т.к. не хочу менять компьютер, только потому что на нем условный текстовый редактор тормозит. И вашим приложением тоже не буду пользоваться. Благо пока нативных приложений хватает.
Обертка для веб-сайтов имеет свою узкую нишу применения. Не надо его использовать везде. Да тот же скайп как пример. Нативное приложение ресурсы не ело и было отзывчивым и удобным. Как только запихнули в электрон, так пользоваться стало жутко неудобно. Пришлось отказаться.
kuza2000
12.02.2019 18:15+3200 мегабайт… когда-то я работал на машине, которая имела 0.5 Мб памяти… она обслуживала 50 рабочих мест онлайн, рассчитывала зарплату для предприятия со штатом около 5000 человек. Там была кадровая база и много чего. А жило все это на двух жестких дисках по 20 Мб каждый. Технический прогресс, однако…
dimansny Автор
12.02.2019 18:27Вспоминается знаменитая история с диалогом о БЭСМ-6:
— Представляешь, когда-то у каждого человека дома будет стоять ЭВМ, сравнимая по производительности с БЭСМ-6.
— Неужели в будущем все будут настолько умными, что каждому нужна будет дома БЭСМ-6?
opckSheff
13.02.2019 06:58Неужели в будущем все разработчики будут настолько глупыми и ленивыми, что каждому нужен будет для элементарных задач процессор с вычислительной мощностью в сотню-две гигафлопсов и вдобавок пара десятков гигабайт оперативной памяти?
Ой… Как-то не заметили, а будущее уже наступило.
pmcode
12.02.2019 18:21+1Не рассматривали вынос «бэкенда» приложения на Rust, например. Вот тут один разработчик делился таким подходом. Жалко нет данных, насколько это может повлиять на потребление памяти. Если Electron будет отвечать чисто за отрисовку UI, и при этом отъедать не больше чем обычная браузерная вкладка, то возможно есть смысл заморочиться.
Недавно, ради интереса, попробовал написать небольшое приложение с OpenJFX11 + сборка его же в виде runtime image. Потребление RAM 150Mb+, со старым ParallelGC — 120Mb+. Т.е. оно примерно в той же весовой категории, что и Electron, ну только что Java как бэкенд более производителен.dimansny Автор
12.02.2019 18:47Пока не рассматривали такой вариант. На данный момент «бэкенд» приложения достаточно прост, думаю будем присматриваться к подобным решениям в случае возникновения проблем с производительностью в конкретных местах.
rgs350
12.02.2019 18:24+6Все похожие статьи можно существенно сократить:
Почему мы выбрали электрон?
Здравствуйте.
Дешевле.
Спасибо за внимание.
Аргумент веский, но КМК подходит не для всех приложений. Для обычных пользователей может и зайдет — они не разбираются электрон это или не электрон. Для разработчиков/админов и.т.д. только если приложение предоставит им больше возможностей чем конкуренты.
Как-то обсуждали электрон и сошлись во мнении что: «За деньги я вам напишу что угодно и на чем угодно, но сам использовать не буду».
Так, мысли вслух.fogx
12.02.2019 20:52Только не «дешевле», а «большую часть оплатят пользователи», ежедневно, каждый. А нам-то да, выйдет дешевле.
dimansny Автор
12.02.2019 22:00+1Стоимость разработки нативных кросплатформенных приложений может быть настолько дороже (как минимум в нашем случае), что разработку лучше не начинать вообще. Вы считаете, что отсутствующее приложение лучше, чем приложение, которые покрывает кейсы, не побоюсь этого слова, большей части пользователей?
Groramar
12.02.2019 22:12Не нужно сказок. Delphi/Лазарус существенно дешевле разработки на JS, по собственному опыту, используем и то и другое у себя в компании довольно давно (Delphi — 15 лет, JS — 10). Delphi/Лазарь сейчас работает практически на всех платформах, от утюгов (Лазарь, распбери — запросто) до Веба (есть пяток решений, от транспилляторов pas > js до ExtJS обёрток). Работает практически с одним кодом. Мы пишем в продакшне, Винда, Линукс, Веб (частично — 'чистый' JS, частично — UniGUI).
Всё нативное, само собой.
Лазарус, если что, полностью бесплатный. Delphi бесплатный с ограничениями по доходам.dimansny Автор
12.02.2019 22:30-1Ну как ты вы лихо все приложения под одну гребенку подвели. Ну как минимум, нам нужен редактор для работы с подсветкой синтаксиса, автодополнением, статическим анализатором js кода, наличием встроенных подсветок синтаксиса. Плюс должна быть поддержка запуска скриптов на одном из популярных язков (jvm-based или js). Нас не устраивает как выглядят нативные компоненты, поэтому нам бы хотелось выбрать что-то стороннее.
Ну и в завершении по поводу дешевизны разработки на Delphi/Lazarus. Зашел на сервис зарплат в моем круге (лучше, извините, ничего не придумал) чтобы оценить во сколько раз отличается количество delphi и js разработчиков. Delphi — 24 разработчика, js — 9147 разработчика. Разница просто колоссальная и она в целом отражает ситуацию на рынке — на js найти разработчика проще, чем на delphi, я думаю вы спорить не будете. Ну а между проще и девешле фактически можно ставить знак равенства.
В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.Groramar
13.02.2019 00:17В общем не понятно, на основании чего сделан вывод о дешевизне разработки на delphi.
По собственному опыту. Выхлоп отличного Delphi программиста против выхлопа отличного JS. Зарплата получается примерно одинаковая, но отдача не сопоставима, увы.
Людей найти можно и тех и других.
Большинство из того, что вы перечислили скорее всего есть в виде готовых Delphi компонент. Собственно — сама Delphi (IDE) написана на Delphi.
iroln
12.02.2019 20:53+7Каждое приложение на electron потребляет какое-то совершенно невероятное количество ресурсов: оперативной памяти и процессорного времени, что никак не коррелирует со сложностью и функциональностью приложения. Каждое приложение на электроне тормозит и фризится даже на мощных рабочих станциях. Даже хвалёный тут и везде vscode. Одно, второе, третье приложение на электроне и вот уже мощная рабочая станция превращается в тыкву… гори в аду, electron!
Filippok
12.02.2019 21:30+4десктопные приложения позволяют использовать любые языки программирования вплоть до ассемблеров, эффективно использовать ресурсы системы, применяя многопоточное программирование и низкоуровневые инструкции.
…
В итоге, мы остановились на ElectronВам не кажется, что тут взаимоисключающие параграфы?
dimansny Автор
12.02.2019 21:46Ну во-первых здесь не сказано, что имеено сейчас нам это нужно, достаточно самой потенциальной возможности. Во-вторых, к Electron-у можно писать нативные расширения, что позволит ускорить конкретные места. Поэтому нет, не взаимоисключающие
Neikist
12.02.2019 21:50+4Читаю комментарии и прямо радуюсь что все таки не один я такой. Если вижу что приложение имеет в своей основе электрон, react native и подобные технологии быстрого приготовления — удаляю, оставляю только если нет альтернатив или приложение не вот прям обязательно по каким то причинам.
Groramar
12.02.2019 22:14+1Надеюсь, разум всё таки победит. Динозавры же вымерли? Есть надежда, что и текущее состояние дел не на всегда.
aleki
12.02.2019 22:25-1Вы своим поведением напоминаете пользователей IE, которые пафосно заявляют, что если сайт в должной мере не поддерживает их любимый браузер, то они не будут им пользоваться. Смешно, глупо, но это их право, которое, правда, не решает в конечном счёте ничего.
Это не значит, что я поддерживаю использование электрона крупными компаниями вроде M$, которые запросто могут позволить себе написать нативно под сколько угодно платформ, но небольшим компаниям лично я такое прощаю. Тем более, что в ближайшее время большая часть из них станет PWA и не будет тянуть за собой целый браузер.
Neikist
12.02.2019 22:42+1Да, PWA это отдельный ужас и боль. Если серьезно — то альтернативы web based фреймворкам и технологиям надеюсь в скором времени появятся. За Microsoft не слежу, хотя из долетавших до меня слухов он в этом направлении двигается, но например под мобилки от google вполне годный по архитектурной задумке flutter выходит. Да, пока только вышел, но в целом на мой взгляд перспективы есть у технологии как в плане быстрой и дешевой разработки, так и в плане производительности и расширяемости, тем более что можно подключать вполне написанные на других языках вещи. Также любопытно куда kotlin двинется. Ну а то что я стараюсь не пользоваться по возможности электрон/реакт нейтив приложениями — тут конечно не всегда меня такие продукты не устраивают по своим потребительским качествам (не зря себе комп собирал за 3 зп), но таким образом я кладу очередную песчинку на чашу нативных и компилируемых технологий против веба.
aleki
12.02.2019 22:48И чем же PWA — ужас и боль?
Flutter, имхо, хорошая вещь, но под desktop платформы официальной поддержкой не пахнет. Да и странно, что React Native вам не нравится, а Flutter, внезапно, нравится.Neikist
12.02.2019 22:54React Native в итоге все же исполняет js, да еще и с мостом к нативу, в отличие от флаттера который по примеру всяких фреймворков для игр рендерит все сам, не имеет никаких мостов, да и код даже сейчас уже практически в натив под железо компилируется (хотя там вроде есть отдельные но) если не в дебаг сборке. Насчет флаттера под десктоп — есть вероятность что появится (учитывая то что для веба он вполне оффициально пилится и есть репа с flutter-desktop, пусть судя по всему просто эксперимент)
А PWA это все те же js+html+css.aleki
12.02.2019 23:05От того что Flutter рендерит все сам есть и плюсы, и минусы. Как минимум UI из-за этого медленнее, чем у React Native. Кто вам сказал такую глупость, что у Flutter'а нет «мостов»? Все также, как и с React Native в этом плане.
Все ещё не вижу ответа на вопрос, почему PWA — ужас и боль?Neikist
12.02.2019 23:25Почему медленнее? Как раз из за того что нет моста он и получится быстрее. Есть мосты к вещам вроде геолокации и подобным, но между кодом и UI мостов как раз нет вообще (хотя из того что я понимаю есть деление что рендерингом skia занимается, а код исполняется тот что скомпилирован из дарта — но по факту там нет накладных расходов практически, ибо это все равно что из C какую нибудь либу дергать).
«PWA это все те же js+html+css» — что означает все те же проблемы что и с вебом в виде зависимости от js (ибо даже при транспиляции именно js будет в итоге), тормозов (несмотря на jit'ы)aleki
13.02.2019 21:28Быстрее, ага. Особенно webview или google maps. И мостов совсем нет, ага. /0 Хотя бы почитали бы отзывы в Google Play на Flutter Gallery. Куча проблем с производительностью.
На вопрос про PWA аргументированного ответа я так и не получил.
rgs350
13.02.2019 19:02И чем же PWA — ужас и боль?
Яндекс.Избач (дополнение для Яндекс.Метрики) — не только мониторит действия пользователей на сайте, но и вероломно шарится в их компьютерах. Ура! (надеюсь шутка).aleki
13.02.2019 21:30Эм, PWA не дает доступа к FS. А если и будет, то будет просить соответствующее разрешение. К тому же, метрика сейчас везде есть и не зависит от технологий, так что к чему это вообще?
kotokur
12.02.2019 22:46-1А я тут посчитал, у меня на ноуте прямо сейчас пять приложений на Electron работают и ничего не тормозит, ОЗУ больше половины свободно. Что тут все обсуждают не понятно)
Neikist
12.02.2019 22:55+2Дайте угадаю, стоимость вашего железа 50к+?
kotokur
12.02.2019 23:43При нынешнем курсе с таким предположением трудно промахнуться :)
Neikist
13.02.2019 00:15Вот и у меня 70+. Правда есть проблема что например иногда хочется что то поделать на ноуте за 16к (в деревню беру, или на прогулки). Да и в целом в провинции немало людей у кого ЗП немногим больше чем те самые 16 гигов памяти.
V1tol
12.02.2019 23:08+3Это до тех пор, пока вы не начнёте в этих приложениях работать. У меня рабочее окружение — Slack, Skype, Postman и VSCode. Примерно через 7 часов после запуска эта братия начинает дружно подвисать и тормозить различными способами. Это на 9700К и 16 гигах оперативки! Причём самое странное то, что по монитору ещё есть пару гигов свободной памяти и процессор не нагружен. Есть подозрение, что вся эта электронная муть своим жеесом под конец дня дико фрагментирует оперативку, отчего и фризы возникают. Перезапуск лечит ещё на 2-3 часа, дальше приходится перезагружаться. Это мне теперь нужно ещё 16 гигов докупать, чтобы гонять 4 электрона без проблем хотя бы часов 10?
kotokur
12.02.2019 23:35Ну я, конечно, немного масла в огонь подлил, проблема мне в общем понятна, но меня самого всерьез никогда не беспокоила. Таких проблем как у вас у меня не возникает точно, на вашем месте я бы все проклял :). Из всех Electron приложений, включая Skype, притормаживал только Gitkraken и то на данный момент все уже исправили. Система перезапускается только в момент обновлений, когда без этого никак, все остальное время спит. То есть неделями все работает без перезапусков. ОЗУ 16 гб, если б было 8, наверное, все было бы грустнее.
V1tol
13.02.2019 17:26Я как-бы точно не диагностировал виновника, но большую часть сьедает Slack (там 2 организации по 50+ чатов) и, естественно, VSCode (легаси проект на NodeJS с файлами по 8 тысяч строк кода). Но то, что виновник — электрон, я уверен на 100%. Если сидеть в телеграмме и XCode, то даже с утечками памяти в икскоде (когда приходится убивать SourceKit, сожравший 13+ гигабайт) можно более-менее спокойно работать весь день.
sedyh
12.02.2019 23:48+1C#, TypeScript, Go
Могу я узнать, почему вы не смотрели в сторону jvm?
dimansny Автор
12.02.2019 23:54-2Не сильно знакомы с данной экосистемой
Steamus
13.02.2019 00:46+2Рискну показаться категоричным, но на сегодняшний день действительно сильными кроссплатформенными десктоп инструментами (с поправкой в том числе и на количество доступных специалистов на рынке) являются Qt (C++) и OpenJFX (Java и со.). Все остальные либо сырые, либо немного устарели, либо просто «модные».
tamapw
13.02.2019 09:43… на сегодняшний день… (с поправкой в том числе и на количество доступных специалистов на рынке)… и OpenJFX ..
Я, конечно, практически не изучал данный вопрос, но разве по FX есть достаточное количество вакансий\проектов\специалистов? Да даже хотя бы обширное коммьюнити с достаточным количеством мануалов и гайдов?
Чисто по внешнему впечатлению, развитие этого продукта остановилось, им никто не интересуется, статьи о нём не пишутся на тот же хабр. Не слышал о нём за последние два года ни разу, вот от вас только, хотя постоянно слежу за общим фоном Java-мира.
Пробовал изучать FX и просто по удобству использования использования и удобству разработки сравнивал с шарповыми WinForm\WPF, которые под mono спокойно запускались на линуксах в том числе. Сравнивал чисто в пользовательском смысле.
И, FX безумно проигрывал по скорости разработки и удобству. Безумное количество лишних действий, которые не удобны в том числе из SceneBuilder. И сам SceneBuilder тормознутое, топорное и чудное… было пару лет назад.
Я, разумеется, его не правильно готовил, с этим спорить не приходится, тем не менее — общее состояние дел как-то изменилась за эти два года или всё примерно на том же уровне? Использовал FX-8Steamus
13.02.2019 18:11Хайпа давно никакого нет, потому как сейчас десктоп инструменты не провоцируют хайпы в принципе. Столица плавно переместилась в Веб. Опять же — инструменту уже 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.tamapw
13.02.2019 19:33Ох, благодарю за развёрнутый ответ.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть.
Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным
Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.
Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.
Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.Steamus
13.02.2019 22:08В JavaFX, как и в Swing, при прочих равных, стараются избегать абсолютного позиционирования (разные платформы, разные шрифты, разное разрешение...), а предпочитают использовать специальные layout managers. Это контейнеры, которые расставляют расположенные на них визуальные объекты по определённому закону. В виде сетки, разбивая на некие группы, поддерживая нужные расстояния между ними, меняя их размер с изменением размера охватывающего контейнера ну и прочее. Есть несколько стандартных, есть написанные сторонними людьми. Ну и свой можете написать. SceneBuilder также предлагает класть их как подложку, что некоторых может озадачить, если раньше не сталкивались с таким подходом.
По поводу цикла статей. Есть проект на гитхабе, где человек собирает ссылки на материалы, касающиеся JavaFX. Сторонние библиотеки/фреймворки, книги (их уже много, потому неактуально), статьи, блоги etc. Сейчас, когда материалов уже много, это менее актуально, но тем не менее. Опять же JavaFX работает для всех языков программирования доступных на Java машине (Clojure, Groovy, Kotlin, Scala, Ceylon, JRuby, Jython, Nashorn (это вариант javascript)).
staticlab
13.02.2019 23:07+1Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет
Для Swing неплохой визуальный редактор есть в NetBeans.
pmcode
14.02.2019 10:27Далеко не все так радужно как вы описываете:
* OpenJFX версионно не связана с OpenJDK, это так, но при этом они придерживаются одного графика выпуска релизов.
* После того как JavaFX выкинули из JDK она естественным образом также стала platform dependent. При этом, если, например, вы еще можете найти 32-битную сборку OpenJDK для Windows, то для OpenJFX нет.
* OpenJFX не развивается годами. По сути, все что было сделано в промежутке от JavaFX 8 до OpenJFX 11, это выпиливание JavaFX и подержка JPMS. Я не говорю про новые фичи (хотя очень хотелось бы), но ведь даже от таких позорных багов не избавились за 7+ лет.
* Заявлять что JavaFX порреживает HTML5 и минимальный веб-стэк конечно можно, но с оговорками. А именно то, что компонент WebView, который построен на Webkit нереально жирный. От 300-400 метров памяти он съет как нечего делать, плюс добавит немаленький лаг при начальном запуске, так что я лично на него просто забил.
* JavaFX точно не относится к классу легковесных решений. Какой-нибудь Hello World еще будет компактным, а вот приложение с относительно сложными формами уже нет. Вы платите ресурсами за каждый компонент, и платите больше чем в native (и больше чем в Electron).
kotokur
12.02.2019 23:54И Delphi
dimansny Автор
12.02.2019 23:57-1Зря передергиваете. В соседней ветке спор по теме на чем дешевле разрабатывать так и не был разрешен.
Alhymik
13.02.2019 03:38sciter не смотрели для вью? в связке хоть с чем для бизнес-модели (c++, c#, delphi и т. д.). Вроде интересное решение.
sticks
13.02.2019 08:08Как-то пытался сделать простое pet-приложение на нем. В итоге столкнулся с тем, что Sciter достаточно сырой под Linux, и вокруг него все равно приходится городить огород из кусков WinAPI/GTK+. Ну и в минусы: закрытые исходники, один разработчик (который, впрочем, достаточно оперативно фиксит баги и пилит фичи по запросу), статическая линковка и доступ к исходниками за деньги. В общем, для некоммерческого хобби я бы его взял, для разработки коммерческого приложения, с которого собираюсь получать доход — нет.
math_coder
12.02.2019 23:49+2Потому что у вас нет совести. (Но это нормально — совесть бизнесу обычно мешает.) Всё остальное (написанное в статье) — вторично.
vladkorotnev
13.02.2019 03:47Эх, чем больше приходится сталкиваться с постманом и подобными поделками, тем больше жалею, что забросил в далёком 2009 писать GUI для libcurl аж на RealBASIC. Функциональности было столько же, летало как нативное, только вот со временем проще стало запоминать команды, чем поддерживать эту жесть. Но как минимум оно умещалось в пару мегабайт оперативки, чего для её задачи в принципе-то всё ещё слишком много.
pawlo16
13.02.2019 07:29Имхо нативные приложения для десктопа на чём бы то ни было приятнее и использовать, и разрабатывать, и распространять.
По поводу электрона — разработка под веб значительно сложнее, чем под десктоп, будь то даже Qt на С++. И инструменты под веб относительно не очень. Потому годится электрон только для таких кейсов как у Вас, когда в команде большой экспириенс в js, и мало в других языках.
mogrein
13.02.2019 10:39В представленных примерах приложение на электроне либо опенсорсное, либо бесплатное (иногда есть отдельные платные фичи завязанные на внешний сервис). Ни слова о том, как у Electron обстоят дела с обфускацией кода и защитой от отладки, что весьма интересно для приложения на котором хочется делать бизнес.
squizduos
13.02.2019 10:39Основная проблема приложений на Electron — это не только невероятное количество потребляемых ресурсов, но и отзывчивость интерфейса. И вот это уже ставит крест на вашем приложении.
Потому что многие разработчики критичны к этому параметру, и не будут в качестве рабочего инструмента использовать что-то тормозящее.
Я так и не понял, чем вас не устроила связка Qt/C++. Почему упор на C#?
Electron обычно используется по причине дешевизны разработки — потому что высокая степень унификации между веб-версией и десктоп-версией в плане кода. Но у вас такой проблемы не стояло — и выбор от этого «браузера в окне десктопного приложения» выглядит ещё более странным.
Потому спасибо, но нет.
Spiritschaser
13.02.2019 10:47Почему вы выбрали electron?
Потому что ничего не знали про wx, например.
Wxnode, если хотите JavaScript.
Его, кажется, только под c# кросс-платформенный нет. Технологии (платформе?) более 20 лет, и она поддерживается и развивается. Думаю, даже когда JavaScript станет многопоточным и в нём запретят 1+'1' и подобное, wx будет развиваться.dimansny Автор
13.02.2019 11:16Самая первая фраза в readme репозитория
Feel free to use this module but, I am no longer supporting it in favor of AppJs
Ну и последний коммит 7 лет назад.
staticmain
13.02.2019 11:38c# кросс-платформенный
Нет. Mono как был обрубком, так и остается.
www.mono-project.com/docs/about-mono/compatibility
Слово «кроссплатформенный» нельзя применять к различиям между Windows 7 и Windows 10, как делает Microsoft в своих рекламных материалах.olegfil
13.02.2019 13:05Ой.
А мой код из нескольких проектов написаный на С# работает на Linux, MacOs, iOs и Android.
Что я делаю не так?staticlab
13.02.2019 13:23А какой тулкит использовали, если не секрет?
olegfil
13.02.2019 13:32Для 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 — она для индивидуального разработчика дает фактически все тоже самое что и платные версии.staticlab
13.02.2019 13:38Так получается, что у вас всё равно разные технологии для UI на разных платформах, а для линукса и мака вы десктопные приложения в принципе не пишете?
olegfil
13.02.2019 13:49я писал ответ на
"
«c# кросс-платформенный»
Слово «кроссплатформенный» нельзя применять к различиям между Windows 7 и Windows 10, как делает Microsoft в своих рекламных материалах."
На языке C# я могу писать под разные OS и оно будет работать, но да — пока нельзя писать десктоп под Линукс и Мак.
Будем ждать WPF — она пока перебирается на .NET Core и может уже потом под нее сделают движки для Linux и Mac. После перевода на .NET Core и открытия всего кода это будет уже значительно прощеstaticlab
13.02.2019 13:58Просто вопрос о кроссплатформенности UI в контексте статьи и ссылки на Mono Compatibility как раз очевиден.
pawlo16
14.02.2019 08:45«WPF перебирается на .NET Core » — это не правда, ничего подобного и близко нет. Загуглите что означает буква W в аббревиатуре WPF. Посмотрите как она устроена внутри. Посмотрите, когда вышел последний релиз. Эту библиотеку закапывать пора, а не портировать на линукс.
NightFlight
14.02.2019 02:34Не для полемики, а из любопытства: а Xamarin + Xamarin.Mac чем не устроили?
Я почему спрашиваю… Я бы такую задачу решал на Delphi, но это чисто личный выбор. У меня команда вся на Delphi пишет, куча отлаженного кода и нужных классов, большой опыт разработки на Delphi для Win и Mac. Но если бы я был не я, а какой-нибудь более молодой человек, без «наследства», который может выбрать любой инструмент чтобы начать проект с чистого листа? Я никогда не пользовался Xamarin + Xamarin.Mac, но из того, что я слышал, вроде бы это то что надо, и не нужен никакой Electron с большим RAM usage и противненьким ненативным рендерингом шрифтов? Или я что-то упускаю?dimansny Автор
14.02.2019 14:05Ну во-первых его нет для linux. И он бы нас не устроил уж очень малым набором готовых компонентов. К примеру, тот же самой редактор с подсветкой синтаксиса самим писать не хотелось.
karl93rus
Ваше приложение это аналог Postman?
dimansny Автор
Мы пересекаемся по функционалу с постманом. Однако, у нас есть ключевые отличия:
1) Возможность создавать сценарии запросов (создать сущность -> получить сущность чтобы проверить, что она существует -> удалить сущность)
2) Создания тестов без программирования. Мы имеем конструктор assertion-ов, который позволяет создавать их из UI. В случае сложных тестов вы так же можете написать скриптовый assertion на javascript.
3) Человекочитаемый формат проектов (базирующийся на yaml). Это позволяет синхронизировать проект через системы контроля версий с возможностью code-review и т.д.
4) Автокомплит переменных, заголовков, протоколов и т.д.
redskif
По поводу 3 пункта. Если это будет действительно удобно, хотя на примере Postman не совсем представляю себе как это возможно, то это будет наверное основной киллер-фичей.
Жду от вас статью уже для тестировщиков, где вы наверное расскажите про этот пункт и п.1 подробнее.
dimansny Автор
Да, мы как раз собираемся опубликовать статьи тут. Более того, они уже есть в английской версии в нашем блоге:
testmace.com/blog/2019/01/28/testmace-beta-features-overview-part-1
testmace.com/blog/2019/01/28/testmace-beta-features-overview-part-2
Русскую версию выложим тут в течении недели наверное.