Electron — это один из самых известных инструментов современного разработчика. Если присмотреться, то это родственник Reactive Native, манящий лозунгом «пиши один раз, запускай везде!», но с гораздо меньшими издержками по сборке и релизу, чем в случае мобильной разработки. Его уникальное преимущество заключается в комбинации Node.js и Chromium, создающей мощную десктопную среду для веб-технологий. Официальный блог Electron не так давно отметил своё десятилетие, что весьма удивляет с учётом того, насколько глубоко этот инструмент успел проникнуть в культуру разработки.
К середине 2020-х мы достигли точки, когда новое ПО чаще всего начинается в виде сайта (с использованием типичного стека HTML/JS) и позже для повышения эргономики расширяется на десктопные системы — будь то в виде значка панели Dock, упрощённой интеграции в ОС или просто более специализированного рабочего пространства. Этому паттерну следовали ChatGPT и Perplexity, даже если не переходили на использование Electron. И всё же для многих команд, желающих собрать приложение в кратчайшие сроки, Electron позволяет практически мгновенно получить кроссплатформенную поддержку и обеспечивает столь желанные преимущества веб-среды вроде автоматических обновлений и беспроблемных релизов.
Когда нашим инженерам в Graphite потребовалось легковесное десктопное расширение, мы тоже без раздумий обратились к Electron — особенно, когда увидели возможность авто-обновления. Но я часто задавался вопросом: откуда конкретно взялся столь влиятельный фреймворк? И ответ меня немного удивил — его создали разработчики GitHub.
▍ Эпоха до Electron
История Electron началась не так давно — всего лишь в 2013 году. Ещё до распространения техники поставки веб-приложений в десктопных обёртках разработчики, как правило, писали полностью отдельные нативные решения для каждой платформы. Нужна поддержка Mac? Пишите на Objective-C или Swift и разбирайтесь с Cocoa. Хотите поддержку Windows? Готовьтесь попотеть над C++, C# или .NET. Linux? Ещё веселее. У каждой платформы свои парадигмы UI, идиомы кода и пайплайны сборки, так что согласованное обслуживание мультиплатформенных приложений было болью. Многим командам в итоге приходилось обслуживать по две, а то и три базы кода, каждая из которых имела свои тонкие отличия.
Некоторые кроссплатформенные наборы инструментов вроде Qt или JavaFX предлагали частичное решение этой проблемы, но зачастую вносили сложные уровни интеграции, несогласованную работу UI, а порой и нестабильное быстродействие. Тем временем язык Java посредством своей JVM обеспечивал широкие возможности, но для клиентских десктопных приложений являлся довольно сложным решением. Да, он позволял вам «писать один раз и запускать везде», но не все горели желанием осваивать Swing или JavaFX для создания современного UI. А если вам требовалось написать приложение конкретно для веб-среды, то JVM уже не годилась.
Так что, если вернуться год так в 2010, то создание кроссплатформенного десктопного приложения зачастую было сравнимо с карабканьем в гору по колено в снегу.
▍ Как появился Electron
Но вернёмся в 2013. Создал Electron один из инженеров GitHub, Ченг Жао, и изначально назвал его «Atom Shell». Причём создавал он его не в качестве альтруистического порыва на благо опенсорса, а конкретно для редактора Atom, нового «настраиваемого» редактора GitHub, который опирался на веб-технологии (HTML, CSS и JS), но должен был также работать на десктопе.
Платформа GitHub спонсировала и взращивала этот фреймворк с самого его рождения, поэтому он быстро окреп за счёт тестирования в реальных условиях, обратной связи от разработчиков и обширной базы пользователей — по сути, сообщества Atom.
Иронично, что хоть Atom в итоге и оказался в тени Visual Studio Code, его фреймворк становился всё более зрелым и универсальным. Всего через пару лет «Atom Shell» был переименован в Electron и в 2016 году достиг своего первого устойчивого релиза 1.0. После этого произошло переломное событие: Microsoft начали поставлять VSCode на базе этого фреймворка, чего оказалось достаточно, чтобы сделать его популярным среди многих корпоративных команд разработки.
▍ Взгляд изнутри: ключевые технические решения
Реальным прорывом Electron стало совмещение Node.js и Chromium. Это решение позволило JavaScript взаимодействовать напрямую с нативными возможностями ОС, в то же время отрисовывая браузерный UI, тем самым обеспечив крайне желанную для многих веб-разработчиков комбинацию. Такую многоцелевую архитектуру удалось смоделировать на базе следующей функциональности Chromium:
- Основной процесс: обрабатывает задачи уровня приложения, такие как создание окон, подключение к API операционной системы и управление общим жизненным циклом. По-сути, это «мозги» вашего приложения Electron.
- Процессы отрисовки: каждое окно или «представление» выполняется в собственном процессе, отрисовывая HTML, CSS и JavaScript. Такая изоляция повышает стабильность, поскольку сбой отрисовщика не обязательно приведёт к сбою всего приложения.
-
Автоматические обновления: Electron имеет встроенный модуль
autoUpdater. Легко забыть, что автоматические обновления в нативном ПО традиционно были диковинкой. В случае же Electron вы получаете их с минимумом хлопот, что является значительным преимуществом при частом развёртывании патчей или инкрементальных релизах новой функциональности.
И такая структура сильно облегчает для нагруженной команды фронтенда релиз десктопной версии веб-приложения. Именно поэтому многие стартапы склоняются к Electron, ведь зачастую быстрый вывод продукта на рынок важнее экономии памяти.
▍ Хлопоты разработчиков: раздутие и избыточность
Electron нередко критикуют — особенно по части раздутия. Каждое приложение Electron содержит собственный экземпляр Chromium, так что, если у вас запущены Slack, VSCode и Discord, то одновременно также запущено три копии Chrome. Подобная ситуация ведёт к массивному потреблению памяти и большому размеру двоичных файлов приложений. Типичная программа «Hello, world» на Electron может весить более 100 МБ, что некоторые пуристы считают чудовищным.
Ещё на заре своего становления у Electron были некоторые проблемы со стабильностью. В случае сбоя отрисовки пользователи иногда наблюдали «белые экраны смерти». В конечном итоге сообщество исправило эту проблему, и современный Electron уже намного надёжнее. Тем не менее сопутствующие издержки могут стать решающими для команд, ставящих акцент на производительности и экономии ресурсов.
Если смотреть с точки зрения безопасности, то приложения Electron, в отличие от современных браузерных вкладок, обычно не изолируются. Одна опрометчивая зависимость или небезопасно загруженный скрипт может предоставить злоумышленнику углублённый доступ в ОС. По этой причине очень важно относиться к разработке на Electron с той же серьёзностью, с какой вы бы отнеслись к безопасности нативных приложений: включайте
contextIsolation, ограничивайте возможность удалённого выполнения кода, тщательно подбирайте сторонние пакеты и так далее. Здесь не требуется сверхъестественных усилий — достаточно немного дисциплины. Интересно, что разработчики некоторых хорошо спонсируемых приложений намеренно избегают Electron. Лучшим из актуальных примеров является ChatGPT: несмотря на то, что OpenAI располагает хорошими производственными мощностями, они создают именно нативные клиенты для Windows, macOS, iOS и прочих платформ. Некоторые считают, что они хотят добиться более глубокой интеграции или быстродействия (хотя, согласитесь, если в названии вашего приложения присутствует «AI», вы наверняка постараетесь не тратить вычислительные ресурсы впустую). Тем не менее для небольшой команды такая задача может стать неподъёмной.
Большинство из нас не имеют достаточно ресурсов для создания и обслуживания нативных реализаций, в связи с чем Electron продолжает оставаться популярным.
▍ Tauri и будущее
В процессе своего развития Electron значительно снизил барьер для входа в сферу разработки десктопного ПО. Разработчики, которые когда-то были ограничены возможностями веб-технологий, теперь могут упаковывать свою работу под вид нативного приложения, не прибегая к созданию отдельной базы кода.
Этот подход привёл к появлению новых идей и прототипов, привнёс свежее веяние в область десктопного ПО и породил серию инструментов вроде Atom, Slack и VSCode, которые было бы слишком затратно создавать нативно под все три платформы. На мой взгляд, реальный успех Electron в том, что он превратил «создание десктопного клиента» из пугающей, узкоспециализированной задачи просто в очередной проект выходного дня.
Естественно, не все согласны на сопутствующие издержки памяти или затраты на комплектацию каждого приложения полноценным Chromium. И в результате появились такие фреймворки, как Tauri, нацеленные на решение конкретно этих проблем. Например, тот же Tauri вместо включения в пакет собственного движка браузера, опирается на нативное веб-представление ОС. Одно только это в некоторых случаях может сократить размер базового приложения со 100 и более МБ до 1 МБ. Бэкенд этого фреймворка написан на Rust, что обеспечивает более высокую производительность и безопасность памяти. Кроме того, это определяет более явные границы функциональности ОС, к которой у приложения есть доступ.
Такое решение привлекательно для команд, которые ценят безопасность или просто не могут позволить себе большие расходы памяти. Tauri по-прежнему развивается, но уже предрекает интригующее будущее, в котором удобство использования «веб-технологий на десктопной системе» может сочетаться с небольшими двоичными файлами и более рациональным потреблением ресурсов.
Как человека, который знаком с Electron ещё со времён «Atom Shell», меня поражает его устойчивое доминирование вопреки всей описанной критике. Для большинства организаций скорость вывода продукта на рынок продолжает являться более важным аспектом, нежели его эффективность. Так что в ближайшем будущем Electron наверняка сохранит свою популярность. Тем не менее взгляд сообщества в целом постепенно меняется. Разработчики всё глубже осознают компромиссы между удобством и производительностью, а на рынке уже развиваются альтернативы вроде Tauri, готовые ощутимо изменить текущее положение дел.
Независимо от того, сохранит ли Electron свою корону, или же в ближайшие годы сдаст позиции, он уже изменил наше восприятие десктопных приложений. Благодаря ему, кроссплатформенная разработка стала интуитивной — и даже интересной — а это уже немалая заслуга.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (50)
Mox
17.01.2025 13:12Самое удивительное - что я не могу сказать что VSCode в реальной разработке потребляет как-то радикально больше памяти чем Zed или XCode.
Gorthauer87
17.01.2025 13:12Там там сам UI не очень много кушает, а кушают в основном всякие language серверы. Но Zed все же заметно более отзывчивый, а память нынче дешёвая.
vdudouyt
17.01.2025 13:12А сколько реально "весит" hello world на упомянутом в статье Tauri?
MountainGoat
17.01.2025 13:12У меня на Tauri примитивный скринсейвер есть. Бинарник весит 2.5 мегабайт, инсталлятор 4. Tauri предоставляет свой инсталлятор, который скачает зависимости если у юзера их нет (до 150Мб на win7, ничего на относительно свежей 10ке).
Запущенная программа на Tauri потребляет памяти 3 Мб если мерять так, как меряют апологеты легковесного софта - то есть посмотреть цифру в Task Manager, которая предоставлена без учёта памяти, занимаемой системными компонентами. Если меряться размерами - то пусть меряются с этой цифрой. А на самом деле конечно около 250 Мб.
DjUmnik
17.01.2025 13:12Если каждая мелкая программа будет тянуть свою копию Хромиума, так никакой памяти не напасёшься!
Респект тем разработчикам, которые продолжают писать на нативных языках и технологиях, а не на этой js-вакханалии.
Кто-то сказал, что последняя IDE, написанная на нативном коде из популярных, это QtCreator.
SukhovPro
17.01.2025 13:12А разве Visual Studio перестала быть нативной? (Я про трушную, а не про VSCode :) )
Kerman
17.01.2025 13:12Я пишу db management tool нативно (ну почти), потому что электрон даже близко не может справиться с показом табличек в 100к строк и сотней столбцов. У меня можно и миллион записей смотреть. Оно не всем надо, но это просто гарантия, что оно не затормозит на жалких 10к.
megahertz
17.01.2025 13:12100к строк вы что нативно, что через электрон не будете рендерить полностью, а только текущую часть. Vs code неплохо справляется с редактированием фала на сотни мегабайт.
alevlako
17.01.2025 13:12Миллион записей? На мониторе 8К в портретной ориентации по 130 записей на 1 пиксель? И кто этот шедевр импрессионизма DB и с какой целью сможет увидеть? Когда на экране рисуется только то, что на нем можно рассмотреть осознанно, а это не более сотни строк на экран, то сколько миллионов записей отображать не имеет значения.
muxa_ru
17.01.2025 13:12> Когда на экране рисуется только то, что на нем можно рассмотреть осознанно
Это очень красивая идея, но в разных ситуациях, задачах и софте есть ситуации когда полезно:
- делать поиск через Ctrl-F
- по боковому сроллингу видеть в каком месте открытой простыни ты находишься
- быстро скроллить открытый документ
Yami-no-Ryuu
17.01.2025 13:12Легковесный и Electron в одном предложении - уже шутка. Нет, бывает и круче, например, налоговая прога из 40 формочек на базе Eclipse. Тут скорее Rapid чем Lightweight.
MountainGoat
17.01.2025 13:12Программа на Tauri будет потреблять меньше энергии, чем программа на Qt. За счёт всех браузерных оптимизаций и использования GPU. Ноутбуки спасибо скажут.
Конечно, если не нарукожопить.
TrueRomanus
17.01.2025 13:12Сильное заявление, и Вы конечно же можете его подтвердить ссылкой на бенчмарки?
Wadzhio
17.01.2025 13:12Почему скорость вывода продукта стала цениться больше чем качество этого продукта? Я считаю, что вина в этом лентяев программистов, которые словно Емеля за один месяц хотят обработать землю, посадить культуру, вырастить урожай, собрать урожай и продать урожай. Они ещё не удивляются, что 9 месяцев беременности это слишком долго и накладно?
Ещё мой дед говорил, что работу делай хорошо, а а плохо само получится.
muxa_ru
17.01.2025 13:12Я считаю, что вина в этом лентяев программистов
Они не лентяи а элита и носители прогресса, как их убеждают работодатели в рамках нематериального стимулирования, поэтому, всё что они делают является априори верным.
konst90
17.01.2025 13:12Почему скорость вывода продукта стала цениться больше чем качество этого продукта?
Потому что на быстро развивающемся рынке важно застолбить место. За те восемь месяцев, что отделяет кривой-косой продукт от вылизанного, разработчик кривого наберет клиентскую базу и начнет зарабатывать деньги.
Wesha
17.01.2025 13:12...а копирайт к тому же не позволяет взять Васино овно, вылизать его и начать продавать самому.
AtteroDominatus
17.01.2025 13:12А при чем тут "лентяи-программисты", если скорость вывода продукта это зона ответственности эффективных менеджеров и бизнес в этом заинтересован?
Gay_Lussak
17.01.2025 13:12Вы сами почти сразу ответили на вопрос и тут же сделали неправильную догадку. Да скорость вывода запуска ПО - это определяющий фактор в текущей рыночной экономике. Чем раньше запустил, тем больше заработал. Поэтому программист, выкатывающий продукт раньше, стоит дороже программиста, делающего работу качественнее, но естественно медленнее.
czz
17.01.2025 13:12Потому что мы, пользователи, хотим продукт достаточного качества через месяц, а не идеальный через год и в 10 раз дороже.
Потому что железо можно купить, а время не купить.
Разве нет?
Wesha
17.01.2025 13:12железо можно купить, а время не купить.
А Ви таки куда-то торопитесь?
muxa_ru
17.01.2025 13:12Потому что мы, пользователи, хотим продукт достаточного качества через месяц, а не идеальный через год.
У Вас слишком много опечаток в фразе: "Потому что очень малая, но крайне крикливая часть пользователей оказывает непропорциональное воздействие на умы управленцев разработчиков."
А абсолютное большинство пользователей понятия не имеют о том, что будет какой-то продукт, поэтому у них нет мнения о том, хотят ли они его через месяц или через год.
czz
17.01.2025 13:12У Вас слишком много опечаток в фразе: "Потому что очень малая, но крайне крикливая часть пользователей оказывает непропорциональное воздействие на умы управленцев разработчиков."
Нетъ.
Умы управленцев интересует заработок, а заработать больше можно на той группе, которая более многочисленна. Из этого следует, что управленцы следуют воле большинства пользователей, а не маленькой группы "крикливых".
А абсолютное большинство пользователей понятия не имеют о том, что будет какой-то продукт, поэтому у них нет мнения о том, хотят ли они его через месяц или через год.
Но начнут пользоваться и включат в свои процессы они то, что вышло сейчас, а не то, что выйдет через год.
muxa_ru
17.01.2025 13:12Но начнут пользоваться и включат в свои процессы они то, что вышло сейчас, а не то, что выйдет через год.
Именно так. А произойдёт это через месяц или через год - им пофиг, потому что они ничего и так не ждали.
Да и включат они это в свой процесс не всегда добровольно.
Из этого следует, что управленцы следуют воле большинства пользователей, а не маленькой группы "крикливых".
А можно увидеть исходные данные, на основании которых был сделан вывод о том, что массовые пользователи очень хотели неотключаемые обновления в Винде?
czz
17.01.2025 13:12А можно увидеть исходные данные, на основании которых был сделан вывод о том, что массовые пользователи очень хотели неотключаемые обновления в Винде?
Я немного связан с ИБ, и мне довольно очевидна связь между необновляемыми виндами и ботнетами и распространением стилеров. "Массовые" пользователи ведь хотят сохранности своих денег и файлов? А "немассовые" могут отключить через групповые политики.
Wesha
17.01.2025 13:12"Массовые" пользователи ведь хотят сохранности своих денег и файлов?
Массовые пользователи со своего пика Даннинга тупо не знают, что если нажать на красную моргающую кнопку «УНИЧТОЖИТЬ ВИРУС В МОЁМ КОМПЬЮТЕРЕ!!!» — то именно тогда-то стилер и посадишь. Потому что верят всему написанному. Точно такие же и деньги в МММ несли, потому что Лёня Голубков сказал, что всё пучком.
DaneSoul
17.01.2025 13:12Именно так. А произойдёт это через месяц или через год - им пофиг, потому что они ничего и так не ждали.
Это если вы одни на рынке, а в реальности близкие идеи развивают разные команды разработчиков, и если ваш конкурент зацепит потенциального покупателя через месяц, то на ваш продукт через год этот покупатель возможно даже смотреть не захочет, потому как уже сидит на продукте конкурента.
muxa_ru
17.01.2025 13:12Ну и вдогонку.
Если Вам не сложно, то я бы хотел посмотреть на исходные данные о том, что массовый пользователь хотел чтобы в любой софт начали пихать сбор любых данных.
Ну и, что это массовый пользователь захотел, чтобы софт обновился так, чтобы на его старом железе он тормозил или вообще не мог запуститься.
TrueRomanus
17.01.2025 13:12Для большинства организаций скорость вывода продукта на рынок продолжает являться более важным аспектом, нежели его эффективность.
Звучит если честно довольно дико, потому что эффективность в моем понимании это выполнение задач для которых было создано приложение и если оно (приложение) выполняет эти задачи не эффективно то встает очевидный вопрос о том нужно ли оно вообще.
История Electron началась не так давно — всего лишь в 2013 году. Ещё до распространения техники поставки веб-приложений в десктопных обёртках разработчики, как правило, писали полностью отдельные нативные решения для каждой платформы. Нужна поддержка Mac? Пишите на Objective-C или Swift и разбирайтесь с Cocoa. Хотите поддержку Windows? Готовьтесь попотеть над C++, C# или .NET. Linux? Ещё веселее. У каждой платформы свои парадигмы UI, идиомы кода и пайплайны сборки, так что согласованное обслуживание мультиплатформенных приложений было болью. Многим командам в итоге приходилось обслуживать по две, а то и три базы кода, каждая из которых имела свои тонкие отличия.
Довольно странное утверждение, ведь разработка для Web-а, особенно в 2013 году тоже была далека от кросс/браузерности/совместимости, иначе не существовали бы такие инструменты как AutoPrefixer, Babel, WebPack и прочие. Уже несколько лет стал доминировать один браузер что по сути довольно сильно расхолодило многих разработчик. Но в 2013 были времена когда легко можно было разрабатывая на Chrome открыть свой сайт на Safari и обнаружить какой-нибудь странный баг и наоборот. Это еще не считая разных режимов (типа для людей с ограниченными возможностями и поддержки RTL), разных экранов и много чего еще. Моя мысль в том что для нативной разработки требуется примерно столько же (что тогда что сейчас) сколько и для разработки на Electron, просто многим не хочется что-то изучать когда можно использоваться уже знакомое, создается иллюзия что ты получишь что-то очень дешево. Но опять же Electron не "серебряная пуля" и если надо что-то сложнее чем просто функционал Web вряд ли это будет работа на вечерок.
JBFW
17.01.2025 13:12Некоторые моменты звучат как "глупые пользователи зачем-то хотят чтобы у них программы не тормозили!"
DarthVictor
17.01.2025 13:12С "легковесными" приложениями случились разные операционные системы. Причем в эти разные операционные системы почему-то за 40 лет существования десктопного софта, так и не завезли стандартной кроссплатформенной библиотеки, для десктопных приложений. Браузеры же относительно давно осилили общий знаменатель разработки веб-приложений.
Во-всех современных браузерах ваше приложение будет выглядеть одинаково, в нем будут одинаково работать сетевые вызовы. А за одно и элементы приложения будут в одном и том же месте и дома на "винде" и на работе на "маке", потому что это будет одно приложение, а не два разных приложения с разными дизайнерами и командами разработчиков.
Отдельные приложения под каждую десктопную операционную систему, за редким исключением в лице системных утилит, пользователям не нужны. Они не были им нужны никогда. Они были нужны разработчикам операционных систем для продвижения своих продуктов, которые использовали их для придания "индивидуальности" своим продуктам. Индивидуальность там, правда, на уровне трёх подружек светских львиц, которые стараются одеваться по-разному, но в итогеб все три одеты просто безвкусно.
Отдельные приложения для мобильных приложений, кстати пользователям нужны. Но отдельные от десктопных, а не отдельные для Айфона и Андроида. Что характерно, для мобильных устройств, хоть стандартного стандартного кроссплатформенного гуя и не завезли, но хотя бы выбор нестандартных (Flutter, React Native) больше, чем для десктопа (где сейчас из относительно комерчески популярных только Qt остался, и то очень относительно). При этом и времени и попыток (Avalonia из нового, GTK, аж три десктопных библиотеки от Java) у десктопа было то побольше. Но всем этим технологиям по уровню распространённости и доступности разработчкиков до современного фронтенда очень далеко. Даже вместе взятыми.
А теперь давайте подумаем, сколько времени уйдет у какого-нибудь стартапа на найм команды из 5 фронтенд-разработчиков, которые смогут писать на Electron? Одна неделя? Две? А на Qt? Три месяца? Полгода?
slonopotamus
17.01.2025 13:12Во-всех современных браузерах ваше приложение будет выглядеть одинаково
Во всех браузерах на одном и том же движке, вы хотели сказать? Потому что иначе ответ - конечно нет. Не так плохо как в девяностых/нулевых, но до одинаковости ещё пилить и пилить.
rexen
17.01.2025 13:12Подождите, а как же использование одного браузерного движка для запуска нескольких приложений? Ядро-то одинаковое. У нас же вкладки в обычном браузере шарят движковые ресурсы. Так зачем на каждое Electron-приложение запускать свой Electron? Кажется в Докере похожую проблему решили.
megahertz
17.01.2025 13:12В Linux оно так и работает зачастую. А в других ос это привычная практика каждому приложению тащить одни и те же библиотеки.
NickDoom
17.01.2025 13:12А ещё дешевле и быстрее вообще вместо программистов нанять ассенизаторов. Берётся материал, быстро вылепливается интерфейс, подсушивается и выгружается у клиента. Красота! Прогресс! Или нет?
Мне надо раз было сделать быстро и красиво. Мне нарисовали дизайн — я просто его порезал на спрайты и оживил максимально совместимой версией директдров. Десять метров и работа на любом компьютерсодержащем устройстве. Скорость разработки… ну, скажем так, даже с учётом написания типа прямо аж «оконной системы» (на входе координаты клика, я сам определяю, куда клик попал) — это было просто «ни о чём». Ну чего там писать-то, чесслово? Где там рокет сайенс?
Любая красота в гуях всё равно рядом не валялась с самой простой игрушкой. Почему ж оно жрёт-то больше вдесятеро, чем движок игрушки, даже движок кроссплатформенной игрушки? Чем набиты эти фреймворки, что они столько жрут и в результате на практике используется там примерно то же самое, что уже есть в апи операционки?
dpytaylo
17.01.2025 13:12Интересно, как будет развиваться тот же blitz — голый рендер HTML и CSS, без JavaScript и браузерных фич, для нативных приложений на Rust. Возможно, веб-приложения всё-таки смогут стать ещё более компактными, практически приблизившись к аналогичной производительности нативных приложений (по скорости исполнения и потреблению памяти), благодаря более совершенным подходам.
megahertz
17.01.2025 13:12Библиотеки отвечающие за построение UI на HTML с рендерингом через chromium/os webview/собственный движок стали появляться с девяностых, и сейчас их огромное количество. Но популярность совсем не та.
JordanCpp
Идея понятна. Вместо отдельного процесса электрон с движком хрома, будет запускаться вкладка в браузере с программой. Сути то это не меняет, для того, что бы вывести на экран текст, потребуется загрузить страницу, дёрнуть js либу и т.д Грубо говоря это будет оффлайн страница.
Потому, что не будет больше у вас быстрых и маленьких программ. Вот почему ха-ха-ха
Alinaki
их не стало не потому что Electron
Andrew0610
А потому что 90 процентов пользователей в основном на мобильных устройствах?
Splo1ter
Их не стало, потому что электрон.
Нативная отрисовка в GDI+/ CoreGraphics/GTK намного быстрее, чем пресловутая загрузка js/html
Ну и возьмем другую ситуацию. Гораздо дешевле кроссплатформенная разработка. Деньги решают. Сам работал в компании, которая делала мобильное приложение на Cordova/PhoneGap с применением Angular. Это был тихий ужас. Там native-feel не пахло. Как и в приложениях написанных на Electron.
И в придачу
JS легок в изучении, в отличии от того же C++/QT, C#/WPF/Avalonia