Comments 87
Минимальные требования и объём любой шняги на этом чудо-движке будут >= требованиям nodejs. Не надо мне на компьютер ради софтины конвертирующей температуру тащить ещё одну обособленную версию хромиума.
Для сравнения плагин на pidgin, например, реализующий обмен по протоколу скайпа весит ~1mb, и сам pidgin весит ещё 4. Но проблема, конечно, не в электроне.
А то порой бывает нужно написать какую-нибудь мелочь (типа того же конвертера температур) для собственного пользования, а я со времён VB98 на нативных языках не писал.
если хочется именно IDE, то приятный минималистический вариант — PureBasic. Free version имеет ограничения: максимум 800 строк кода, нельзя использовать API, нельзя создавать DLL.
Компилирует код в standalone приложения небольшого размера (простая форма с несколькими контролами ~50KB).
Попробуйте Qt. В комплекте идёт простая, но вполне достаточная IDE QtCreator. А главное, один раз выучив, можно писать под все платформы практически идентично, включая Андроид. А ещё, если надоест C++, можно перейти на Python: API практически совпадает тоже. С той разницей, что Qt для C++ объявляет примитивы, которые в Python уже есть, а Qt для Python их больше не велосипедит.
Можете сразу с Python начать. PyCharm отличная бесплатная IDE. Да и на VSCode и других про-блокнотах питонить не сложно. На Python можно генерить обособленные EXE-шники. Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.
Но они будут тоже страдать лишним весом в 6Мб на среду и интерпретатор.Ну и с гуём в Питоне не очень. В том смысле, что консоль онли. Только если внешнее что-то подключать. Ну и скорость, как у любых скриптов, на троечку, если не на двоечку. Так что местами там тоже суровая жесть :)
Delphi/Lazarus. Скорее всего свою первую (неконсольную) программу Hello world вы сможете написать минут за 10 :) 9 — просмотр подходящего видео, 1 — остальное.
Delphi Community Edition — отличная бесплатная полнофункциональная среда (ограничение — зарабатываемые на ней деньги, до $5000 в год), блокнотить не нужно :)
Лазарус — бесплатный полностью. Качество постепенно приближается к Delphi и местами превосходит. Сама среда запускается почти на чем угодно, вплоть до утюгов :) Win, Linux, Mac, Raspbery и так далее. Ну и, само собой, собирает под это всё.
community.idera.com/developer-tools/b/blog/posts/announcing-fmx-linux-bundling-with-delphi-and-rad-studio
Я пишу в Visual Studio, но там со времен VB98 ничего не поменялось. Если хотите гуи - берите C++ Builder (он сейчас называется как-то иначе, но суть та же). А так, вроде все пишут на QT, где выходит те же 100метров на хелловорлд.
более того многие не любят никакую версию windows
Вот если бы можно было движок установить раз и навсегда, а не запаковывать внутрь каждого приложения — было бы замечательно.
Просто взрывной рост веба породил кучу лишних js-программистов. Которые теперь пытаются найти себя в десктопной разработке.
В стандартных библиотеках современных кроссплатформенных ЯП до сих пор нет инструментов построения UI, а единственный более-менее работающий кроссплатформеный фреймворк — это Qt, который сам жрёт как пол-Электрона, разве что работает пошустрее. И то для его подключения и интеграции нужно очень уж много лишних телодвижений проделать.
Именно проблему фрагментации и решает Electron. Это среда, которая просто берёт и просто работает. Где вы можете сразу начинать писать кроссплатформенный код без необходимости предварительной установки Kubernetes и всяких виртуалок-контейнеров, чтоб просто собрать ваше приложение под десяток различных платформ.
Где все проблемы с железом и различными операционками берёт на себя разработчик самого фреймворка. И вы можете сосредоточиться на решении именно своей задачи, а не на способах заставить приложение запускаться на очередном экзотическом дистрибутиве Linux.
Я конечно понимаю, что веб-разработчики хотят запихнуть весь софт в браузер, но существуют разумные ограничения. Для десктопного софта существуют соответствующие среды разработки и инструменты.
Мне сложно в это поверить. У меня VS Code с кучей расширений, более плавно работает, чем тот же sublime (без расширений). Памяти конечно больше кушает, но по скорости довольно шустро.
Тот же сублайм на аналогичном проекте занимает 400мб памяти и не тормозит абсолютно.
при этом может гораздо меньше.
На 8 гигах у вас даже встроенный блокнот будет тормозить сразу после запуска системы ибо это минимальные системные требования для современных десктопных ОС. Чтобы не было тормозов, то даже обычному пользователю (не разработчику) надо 12.
И то, что сейчас такие требования к памяти виноват вовсе не электрон, а современный подход к разработке, когда о потреблении памяти и пр. начинают заботиться только когда приложение из за нехватки памяти начинает вылетать у 60% пользователей. Проще говоря, всем, на то, что у вас нет памяти на компе плевать )
VS Code лучше был бы на голом gtk или qt
Это реально афигенная вещь, но именно электрон мне в ней и не нравится, и порой его приходится таки ребутить
По этому у меня он является не лёгким редактором, а полноценным инструментом, давно переделанным в IDE, как лёгкий редактор её заменяет катя от KDE
А Edge по вашему нынче что? Ещё одна обёртка для хромиума blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration
Один движок — одни баги.
В корне не согласен с этим заявлением. Это заявление не имеет реального обоснования! И если уж говорить про десктоп - то Электрон идеально подойдет для реализации именно графического интерфейса, а вот сервисы, которые понадобятся для стабильной работы приложения - здесь можно делать что угодно и как угодно. Можно хоть на расте написать, скомпилить и запускать в обертке под нодой)
Но когда понадобилось переписать три версии приложения для трех разных систем, написанных на разных платформах в разное время и разными людьми, то я был рад, что существует Электрон. Плюс еще получилась готовая не плохая web-версия этого же приложения с той же кодовой базой, так что могу сказать, что я остался доволен.
P.S. Если заменить Resharper C++ на Visual Assist (чем всегда и пользовался), то проблемы пропадают, парсит за пару минут, тормозов нет, функционала в основном больше. Resharper разве что ститический анализ чутка даёт. Но так как не особо он и полноценен, приходится в любом случа пользоваться иными инструментами.
На работе же WebStorm, плюс инструменты необходимые в работе, 8Гб, уже в притык. Есть ещё машина, где уже используется VS Code, и сопутствующее, вот там 8Гб уже не хватает в принципе. Так что да, WebStorm оптимальнее.
Но я ещё помню переход кодовой базы Visual Studio c С++ на .NET и помню повышение потребление оперативки с порядка 200Мб до 900Мб на нашем проекте. Это более показательно, разработчики ПО забивают на потребление памяти, они хотят экономить время скидывая это на потребителей.
Electron по определению использует webkit и никуда от него не деться и он кроссплатформенный, при этом инструменты на Java тоже кроссплатформенны и тут я соглашусь оригинальным сообщением, что всё же решения на Java меньше жрут ресурсов, чем Electron. Но тенденция показанная на базе Visual Studio наблюдается и в использовании Java.
Да и выбирают сейчас JS всё же из-за порога вхождения. К примеру WPF инструмент конечно мощный, но чтобы там сделать что-то большее чем просто конвертор температуры, нужно знатно поучиться.
Соответственно выбор в компаниях, где хотят продукт, но не хотят затрат выбор очевиден. Скайп очень показателен. Они ведь не выбрали WPF, хотя имеют в штате разработчиков знающих WPF на 5 порядочно, да и имеют средства на это.
Visual Studio на базе C++
Это могло быть сказано про v6. Сейчас GUI там активно переносится на .NET
Джава и хороша своей строгой типизацией, и в этом же её недостаток, т.к. в ряде случаев приходится писать дополнительные конструкции для соблюдения этой строгой типизации. Впрочем, эта история характерна для любого кода, где присутствует строгая типизация. Я писал на Электроне и скажу так - надо быстро выпустить работающий прототип десктопа - Электрон в помощь! А уже потом или отдельные части, или все приложение в целом переводится на другой язык программирования по мере необходимости и в случаях, где приложение начинает работать нестабильно или с низкой производительностью. Но... Если надо попробовать запустить какую-то бизнес идею и хотя бы проверить ее на прибыльность, то почему надо сразу брать Джаву, нанимать множество разработчиков и пилить серьезный десктоп?
Помню, как на Delphi меня огорчал размер exeшника. Я даже "огромный" VCL на KOL переписал, знатно покрасноглазив, чем уменьшил размер с 1.5 мбайт до 60 кбайт. А потом еще upx'ом сжимал даже вроде.
Эх, где то мы свернули не туда...
Давайте вместе поможем Даше найти электрон приложения!
но они над этим работают )
Hahahaha! Windows must die, Linux forever!
Или это невозможно?
Из всего того, что я увидел в комментариях, нет ни одного комментария, который бы реально относился к содержанию статьи и был бы от кого-то, кто сам писал на Электроне))) Почему-то у меня сложилось именно такое мнение. Я писал на Электроне, выступал с докладом на конфах и митапах(Secon/Пенза/ и FrontendConf) и был экспертом доклада на TechTrain в прошлом году.
Сразу начну с самого начала статьи. Раздел Electron. Допущена грубая неточность: Electron состоит не из двух частей, как это понимаешь из текста раздела, а из трех равно значимых частей: либа Chromium(уже собранная бинарь. Причем, в ряде случаев очень важно смотреть что за версия электрона у вас, и какая версия либы соответствует ей. Но чтоб попробовать электрон для вас это будет без разницы), NodeJS и Electron API(третья, недостающая часть). См. доку! Там говорится, что библиотека хромиума и нода входят в состав электрона и вам не придется ...(и далее по тексту доки). Но это не значит, что электрон состоит только из этих двух частей.)))
Теперь смотрим на второй раздел статьи "Electron Forge". Опять вижу грубую неточность. Electron Forge - это не фрейворк. Они, конечно, стремятся стать фреймворком, но пока до этого недотягивают. Именно поэтому в доке форджа четко написано, что это набор тулз, объединенный поверх CLI для запуска полноценного пайплайна по пакетированию и дистрибуции приложения на различные ОС. Это очень важно, т.к. фордж не является полноценной системой тулз, которая обеспечит беспрепятственную разработку. Да и, вообще, Фордж - это лишь один из вариантов, как осуществить подготовку релиза десктопа, и это не самый лучший выбор для любого десктопного приложения. Что еще сразу колит глаз - вы фордж устанавливаете глобально?! Зачем это? Что, репы не хватает и надо глобально ставить? По-моему, и в рамках репы его будет достаточно установить.
Теперь про раздел "Структура шаблонного приложения". Пожалуйста, прям, жирнющим текстом выделите, что в данном разделе идет речь именно о том шаблоне, который вы берете для быстрого старта, из имеющихся в фордже. Это, опять же, очень важно! Второй пункт моих уточнений по поводу запуска процессов в рамках ОС - у вас под капотом нода! Вы можете запускать множество фоновых процессов, каждый из которых будет сервисом или микросервисом. Все было верно сказано, что есть Main Process и Render Processes. НО!!! Main Process так называется не потому, что он управляет всеми остальными - эта мысль далека от реальной действительности. Этот процесс так назван потому, что он первый процесс, который запускается при инициализации приложения, и именно тот процесс, который может запускать, но не обязательно, что запускает все остальные. Этот процесс может декларировать для приложения, что в рамках его работы могут использоваться еще и другие. В рамках этого процесса стоит дефайнить ваше апи по работе с процессами вообще. Причем, работа этих процессов должна строиться по мультипроцессной модели, про которую можно почитать хотя бы тут. Упомянутые рендер процессы по факту вам будут нужны лишь для непосредственной отрисовки GUI, и все!) Не стоит из мамы делать папу)))
В целом, спасибо большое за статью! Вы заставили меня вспомнить веселые времена, когда я сам разбирал электрон по болтикам, и что-то написать на хабре, хотя бы этот комментарий) И в качестве дополнения скажу еще одно - Электрон может служить и для разработки мобильных приложений. Уже есть попытки такого использования. Там вся суть в том, какие именно тулзы вы используете для подготовки релиза. Но эти попытки пока остаются попытками. Ничего достойного пока не получилось))) У меня был реальный очень успешный опыт в сфере IoT при разработке касс самообслуживания для торговых сетей Перекресток, Пятерочка, Карусель, Дарвин и др. Поэтому могу с уверенностью сказать, что для сферы IoT Электрон будет в полной мере выполнять все, что вам надо) Также, у меня был опыт ковыряний Qt. На Qt можно написать любое приложение c GUI, но пока в нем разберешься, чтоб хотя бы установить этот фреймворк себе на локальную машину, а, тем более, как там можно создавать десктопы - поседеешь парочку раз точно)
Electron: разработка настольных приложений с использованием HTML, CSS и JavaScript