
Electron — это один из самых известных инструментов современного разработчика. Если присмотреться, то это родственник React 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 ?

Комментарии (236)
Mox
17.01.2025 13:12Самое удивительное - что я не могу сказать что VSCode в реальной разработке потребляет как-то радикально больше памяти чем Zed или XCode.
Gorthauer87
17.01.2025 13:12Там там сам UI не очень много кушает, а кушают в основном всякие language серверы. Но Zed все же заметно более отзывчивый, а память нынче дешёвая.
Areso
17.01.2025 13:12память нынче дешёвая
только если она не распаяна. В обратном случае, она становится дороже наркотиков.
mapnik
17.01.2025 13:12Из чего следует, что vendor lock-in и сектантство тождественны наркомании.
Kenya-West
17.01.2025 13:12Наконец-то я смогу предъявить всем маководам!
RarogCmex
17.01.2025 13:12Приходи к нам в Хакинтош! У нас есть тяжелые соли из шахт Купертино!
А ещё мы скоро помрём вместе с x86_64 маком!
Tim7456
17.01.2025 13:12Вы просто сравниваете 3-х перекормленных монстров и оказывается что все они примерно одинаковые.
Mox
17.01.2025 13:12Что вообщем означает что "нативность" инструмента на масштабе не так уж важна, а Electron не так уж плох.
Потому что по сути ведь сравнение совершенно разных подходовChromium + DOM/CSS + JS
Rust + GPU accelerated UI - по сути подход больше похожий на игровой движок или flutter - то есть рисование на Canvas
Swift (или Objective C?) + Cocoa/UI kit - не знаю на чем именно сейчас написал XCode, но это максимально нативый для операционки фреймворк.
Tim7456
17.01.2025 13:12Нет конечно! Просто добавьте в список другие средства разработки. Например Visual Studio 2018, PyCharm.
И сразу будет заметно, что можно сделать сильно эффективнее без сжирания всей доступной памяти в одно перекормленное лицо.Mox
17.01.2025 13:12Хм, я отказался от IDE от JetBrains именно потому что они ужасно тормозили и жрали память даже по сравнению с вышеозначенными примерами
Может быть сейчас стало лучшеiroln
17.01.2025 13:12Может быть сейчас стало лучше
Не стало лучше. Становится только хуже и хуже с каждым новым релизом.
При этом никаких существенных новых фич не добавляют, баги висят годами. Зато они вкорячивают "AI" во все дырки. Думаю, в следующем году не продлевать подписку. Надоело.
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 Мб.Hlad
17.01.2025 13:12Запущенная программа на Tauri потребляет памяти 3 Мб если мерять так, как меряют апологеты легковесного софта - то есть посмотреть цифру в Task Manager, которая предоставлена без учёта памяти, занимаемой системными компонентами. Если меряться размерами - то пусть меряются с этой цифрой. А на самом деле конечно около 250 Мб.
Эмм, а сколько памяти займут сто экземпляров этой программы? 3*100+250 = 550Мб, или 100*250 = 25000Мб?
DjUmnik
17.01.2025 13:12Если каждая мелкая программа будет тянуть свою копию Хромиума, так никакой памяти не напасёшься!
Респект тем разработчикам, которые продолжают писать на нативных языках и технологиях, а не на этой js-вакханалии.
Кто-то сказал, что последняя IDE, написанная на нативном коде из популярных, это QtCreator.
Filipp42
17.01.2025 13:12Ещё Zed. Я работаю с ним, и радуюсь.
FluffyArt
17.01.2025 13:12Завезли бы еще поддержку работы с гитом как в vscode или idea, было бы очень здорово
SukhovPro
17.01.2025 13:12А разве Visual Studio перестала быть нативной? (Я про трушную, а не про VSCode :) )
slonopotamus
17.01.2025 13:12Она написана после QtCreator?
AbuMohammed
17.01.2025 13:12Ну, с 12й она концептуально другая( впф вместо нетформс), так что, да, после. На самом деле тут после 4 лет за vs code под убунтой пришлось пару месяцев в 22й студии поработать (до линукса было 16 лет за студиями от 6й до 2017й). Божечки ты ж мои, как же я раньше за ней работал, она ж падает зараза ровно каждый час, причем падает падает, вплоть до пропажи последних правок.
Tim7456
17.01.2025 13:12Так она раньше не падала. Я даже больше скажу. Она и месяцами работала стабильно, я на ночь ее и не закрывал. Раз в месяц приходили патчи и машина перезагружалась. А остальное время VS перезапускать и не приходилось. А еще у меня в ней по 200 файлов было открыто. И иногда я мог несколько экземпляров VS открыть для разных проектов. И все это прекрасно работало.
mayorovp
17.01.2025 13:12И до сих пор работает. Я не знаю что надо делать чтобы она падала.
Tim7456
17.01.2025 13:12Ну тут вот товарищ выше пишет, что теперь падает. Либо за последние 4 года начала, либо у него какой-то "особенный" плагин добавлен. Плагины и раньше могли Студию уронить, или всю память сожрать.
Kerman
17.01.2025 13:12Я пишу db management tool нативно (ну почти), потому что электрон даже близко не может справиться с показом табличек в 100к строк и сотней столбцов. У меня можно и миллион записей смотреть. Оно не всем надо, но это просто гарантия, что оно не затормозит на жалких 10к.
megahertz
17.01.2025 13:12100к строк вы что нативно, что через электрон не будете рендерить полностью, а только текущую часть. Vs code неплохо справляется с редактированием фала на сотни мегабайт.
Kerman
17.01.2025 13:12Там не только рендеринг. Это понятно, что виртуальность во все поля. Нейтив это не только рендеринг, это ещё мемори менеджмент. Собственно, держать данные так, чтобы int32 занимал 4 байта в памяти (ну чуть больше с учётом накладных), а не забоксенные 24 я знаю как в нейтиве, но не знаю, как в js
alevlako
17.01.2025 13:12Миллион записей? На мониторе 8К в портретной ориентации по 130 записей на 1 пиксель? И кто этот шедевр импрессионизма DB и с какой целью сможет увидеть? Когда на экране рисуется только то, что на нем можно рассмотреть осознанно, а это не более сотни строк на экран, то сколько миллионов записей отображать не имеет значения.
muxa_ru
17.01.2025 13:12> Когда на экране рисуется только то, что на нем можно рассмотреть осознанно
Это очень красивая идея, но в разных ситуациях, задачах и софте есть ситуации когда полезно:
- делать поиск через Ctrl-F
- по боковому сроллингу видеть в каком месте открытой простыни ты находишься
- быстро скроллить открытый документktori
17.01.2025 13:12А вот есть сайт (на HTML + JS, естественно), где есть поиск с Ctrl+F и быстрый боковой скроллинг с позицией.. для всех UUID4: https://everyuuid.com/ (целых
строк)
muxa_ru
17.01.2025 13:12есть поиск с Ctrl+F
Нет.
ktori
17.01.2025 13:12Сверху выпадает при нажатии Ctrl+F (на Firefox, по крайней мере)
muxa_ru
17.01.2025 13:12Это имитация.
Скопируйте в буфер какой-нибудь идентификатор.
Дальнейшее делайте НЕ СКРОЛЯ ОТКРЫТЫЙ СПИСОК.
Кликните мышкой в адресную строку.
Вызовите поиск по документу в браузере, нажав Control+F.
Вставьте туда скопированный идентификатор.
Строчка найдётся.
Теперь ПРОСКРОЛЬТЕ СПИСОК, так чтобы скопированный Вами идентификатор пропал с экрана.
Снова используйте поиск в браузере (если закрыли, снова откройте, как описано выше).
Строчка не будет найдена.
---
Это сейчас достаточно распространённое явление, когда разработчики х..вертят что-то ну очень стильное и модное, и рядом костылят имитации функционала.
Но это не ОТКРЫТИЕ ДОКУМЕНТА В БРАУЗЕРЕ, а имитация в которое демонстрируется какое-то текущее состояние взаимодействия с сервером.
А раз у вас нет ОТКРЫТОГО ДОКУМЕНТА, то в этой имитации не работает:
- поиск по документу
- сохранение документа в виде файла
- скриншотенье средствами браузераТак же, в подобной имитации может работать криво или не работать вовсе скроленье с клавиатуры.
Ну и, конечно же, каждый создатель такой имитации рисует свой собственный вариант скроллинга, который отличается от дефолтного браузерного, к которому привык пользователь.
Кроме того, в зависимости от рукожопости создателей такой имитации, могут быть проблемы с загрузкой в целом, когда какой-то из яваскриптов ещё не подгрузился и вы не можете взаимодействовать со страницей.
И надо понимать, что вот такие вот имитации делаются не только в арт-проектах "покажем хрендецелион строчек", но и на веб-сайтах, где предполагаемый документ очень конечен.
DarthVictor
17.01.2025 13:12Только что проверил, всё там работает, сайт переопределяет нативный поиск
1) Скопировал UUID из середины: 7edb3b2e-869c-485b-af70-76a934e0fcfd2) Открыл сайт в инкогнито режиме и он всё нашёл
muxa_ru
17.01.2025 13:12Можно увидеть Ваш скриншот?
DarthVictor
17.01.2025 13:12У вас видимо не переопределился поиск на кастомный. Либо вы его из меню открывали. Попробуйте открыть поиск в правом верхнем углу страницы вручную. Именно страницы, а не через меню браузера.
artptr86
17.01.2025 13:12демонстрируется какое-то текущее состояние взаимодействия с сервером
Нет. Виртуализация списка реализуется на клиенте и не требует взаимодействия с сервером.
Ну и, конечно же, каждый создатель такой имитации рисует свой собственный вариант скроллинга, который отличается от дефолтного браузерного, к которому привык пользователь.
Нет. Показать нативный скролл можно. Для этого вычисляется высота списка и задаётся элементу списка явно.
muxa_ru
17.01.2025 13:12Нет. Показать нативный скролл можно.
Если "показать можно", то это подтверждение того что я говорю.
Потому что если "показать можно", то это значит что изначально не показывает.
artptr86
17.01.2025 13:12Нет, изначально как раз показывает, если виртуализация реализована правильно, причём сделать это не сложно. А «кастомный скролл» всегда будет работать неестественно и неудобно, вдобавок его ещё нужно реализовывать или подключать, поэтому он не нужен никогда.
muxa_ru
17.01.2025 13:12Вы сейчас о чём конкретно говорите: о веб-сайте который упомянут выше по обсуждению, о тенденциях в веб-разработке или о чём-то ещё?
artptr86
17.01.2025 13:12О тенденциях и лучших практиках. Обсуждаемый сайт не смотрел, однако думаю, механизм скролла там всё же нативный, а не нарисованный вручную.
DarthVictor
17.01.2025 13:12Конкретно на том сайте это нормальное решение, там список в 2^122 элементов. То есть в нём элементов сильно больше, чем атомов во вселенной.
artptr86
17.01.2025 13:12Решение с виртуализацией хорошее и необходимое, а вот кастомный скроллбар делать не стоило.
alevlako
17.01.2025 13:12Боковой скролинг документа с 1 млн строк в тех условиях, о которых я писал выше, отображает 130 строк в 1 пикселе - по любому нужна кластеризация. И 1 пиксель скроллбара будет соответствовать фактически целому экрану. Открытый документ сидит в памяти и поиск по нему существует, но рисуется только то, что можно видеть. Без хитрой оптимизации тормозить будет по любому, если пытаться производить визуальные компоненты, соответствующие всем записям документа. В экселе, кстати, вроде на 100 тыс строк стоит ограничение длины файла, и не во всех случаях людям хватает.
Mox
17.01.2025 13:12Мне кажется вы что-то не то делаете если вам надо сразу список на 100к строк - есть виртуализированные списки для таких случаев.
I7p9H9
17.01.2025 13:12А как же neovim?
Ок, это не IDE из коробки но быстро им становится с расширениями, а если сразу ставить NVChad, например, то вполне себе IDE.
DieSlogan
17.01.2025 13:12Когда требуется именно app в системе, то пишу на dotNET WPF, планирую переписать всё на MAUI. Это даст поддержку Android, iPhone, MacOS.
Тоже из стека dotNET: Blazor Hybrid. Это WebAssembly, но работающее, как апп, не требующее браузера и с возможностью писать как JS/CSS, так и с помощью XAML. Что не может не радовать.
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Сильное заявление, и Вы конечно же можете его подтвердить ссылкой на бенчмарки?
Queix
17.01.2025 13:12Если речь о QML, он изначально спроектирован для создания динамичных интерфейсов приложений, с отрисовкой на GPU. Думаю, не будет преувеличением, если сказать что производительность таких интерфейсов сопоставима c голой реализацией на C++ и OpenGL. HTML изначально создан для статичных интерфейсов. Даже если создать какой-то облегченный вариант, и выкинуть всё избыточное, что затаскивалось туда десятилетиями, у него останутся накладные расходы на парсинг и поддержание и обновление DOM.
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...а копирайт к тому же не позволяет взять Васино овно, вылизать его и начать продавать самому.
rg_software
17.01.2025 13:12По-моему, эта постоянно повторяемая премудрость звучит логично, но обоснована весьма слабо. Ну вот кто дышал в спину тому же VS Code, и много ли Microsoft на нём заработал? Вышел этот продукт и на и без того забитой поляне, год туда-год сюда ничего бы не изменил. Аналогично Slack. Скайп вообще переписали на место уже существующего Скайпа (с даунгрейдом), то есть их главным конкурентом была предыдущая версия их же собственной системы. То есть контрпримеров несть числа.
konst90
17.01.2025 13:12А тут другая проблема. Когда вам не дышат в спину, а клиентская база набрана - нет никакой мотивации вылизывать продукт, можно продолжать продавать кривой-косой.
rg_software
17.01.2025 13:12Не, это понятно, но вопрос в другом же: почему MS решила сделать VS Code на Электроне, если никто в спину им не дышит, задачи заработать нет, а деньги бесконечные. В таких условиях я бы, как минимум, выбрал собственную технологию -- MAUI или чего там сейчас актуально. Довольно странно рекламировать одно, а самим использовать другое.
ugenk
17.01.2025 13:12Возможно потому что vscode это бесплатное приложеньице? Проприетарная visual studio точно не на электроне написана
rg_software
17.01.2025 13:12Хм, а где связь? Вот вы пишете софт для программистов. Казалось бы, это самый подходящий повод попиарить свою новую UI технологию. Мы ведь когда задумываемся на чём писать что-то новое, смотрим вокруг: на чём написаны X, Y, Z. И вот VS Code -- это же в программистких кругах софт первого ряда, вполне аргумент в пользу Electron, готовая реклама.
ugenk
17.01.2025 13:12Связь в затраченных ресурсах (время, деньги), и полученной выручке.
C VS Code MS врятли получает прямой профит, а VS вполне себе монетизируется с положительным сальдо.
rg_software
17.01.2025 13:12Ну, всё может быть, но мне кажется странно. Зачем тогда вообще писать редактор, что, программистам Microsoft не на чем работать?
Я воспринимаю такого сорта проекты как имиджево-рекламные. Если вы на них экономите, то как же вы в принципе представляете себе продвижиние того же MAUI? Я вот не представляю. "Пишите на MAUI! Мы, конечно, не пишем, но вам советуем". И рекламный бюджет побольше.
jbourne
17.01.2025 13:12Предположение:
Менее важное - JS - самый популярный язык в мире, что облегчает поддержку и развитие (те же расширения)
Более важное - при архитектуре через JS, можно потом легко IDE портировать в браузер и двигать всю разработку в сторону онлайл среды и клаудов, что много дополнительного бабла (GitHub Code Spaces, ...)
И это мне кажетс и есть суть того, почему MS полезло в это - контролировать где сорсы (ГитХаб), как они пишутся (ВС Код), где они пишутся (Азур и онлайн IDE), и кто это пишет (ИИ)
П.С. Я нен конспиролог, но помнится видел старые записи конференций "Build", там где МС представлял ВС Код, и там от всего веяло такими +- целями.
mayorovp
17.01.2025 13:12Не, это понятно, но вопрос в другом же: почему MS решила сделать VS Code на Электроне
Потому что изначально это вообще была не десктопная IDE, а встраиваемая в сайт. Вроде того, как она работает в Codesandbox или в Gitlab.
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железо можно купить, а время не купить.
А Ви таки куда-то торопитесь?
slonopotamus
17.01.2025 13:12Демагогия, подмена тезиса, протестую.
Wesha
17.01.2025 13:12Вы сначала тезис-то напишите, ну, знаете, тезисно.
dyadyaSerezha
17.01.2025 13:12Описываю тезисно. Время - деньги (с) моё. Или я это где-то видел?
Wesha
17.01.2025 13:12время не купить
Время - деньги
Вы там определитесь, что ли...
dyadyaSerezha
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"Массовые" пользователи ведь хотят сохранности своих денег и файлов?
Массовые пользователи со своего пика Даннинга тупо не знают, что если нажать на красную моргающую кнопку «УНИЧТОЖИТЬ ВИРУС В МОЁМ КОМПЬЮТЕРЕ!!!» — то именно тогда-то стилер и посадишь. Потому что верят всему написанному. Точно такие же и деньги в МММ несли, потому что Лёня Голубков сказал, что всё пучком.
nidalee
17.01.2025 13:12Обновления нужны не для того, чтобы шаловливые ручонки не скачали вирус. Обновления нужны, чтобы через дыры ОС вирус сам не пополз дальше.
muxa_ru
17.01.2025 13:12Так массовый пользователь этого явным образом просил или нет?
Astroscope
17.01.2025 13:12Так массовый пользователь этого явным образом просил или нет?
Я, с вашего позволения, чуть сменю вектор. А именно, напомню массовую истерию на разного рода интернет-форумах насчет категорической, буквально жизненной необходимости, обновления прошивок сотовых телефонов. Здесь нелишне будет сделать ремарку, что хорошему, годному продукту обновления как бы ни к чему - у него все доведено до отличного состояния с самого начала, а исправления ошибок - такой себе гарантийный ремонт, который конечно лучше, чем если исправлений ошибок нет, но хуже, чем если ошибки выловлены и исправлены на предсерийных образцах. Но, вернемся к массовой истерии, спорам о том, чей телефон получил больше обновлений и тому подобной ерунде, которую некоторые не только воспринимают всерьез, но и распространяют в реальный мир, "втирая" эти мягко говоря спорные идеи вообще всем, до кого могут дотянуться. Вот вам и запрос на обновления от пользователей - получите и распишитесь. Но почему если обновления предлагает Microsoft для своих Windows, то вместо восторга и экзальтации те, кто только что фигурально говоря рвал глотки за необходимость обновлений, в лучших традициях двоемыслия, не сбавляя ярости и напора, обновления проклинает? Я не пытаюсь найти в этом логику, потому что она там едва ли присутствует хотя бы в следовых количествах. Просто выглядит так, что массовый пользователь не просто просил, а бился в истерике, требуя обновлений. На поверку, наверное, вышло, что никакой это не массовый пользователь, а громко кричащие в интернетах фрики - настолько громко кричащие, что поначалу не верится, что так много шума может создать настолько маргинальная прослойка, но у них таки получилось. А ведь идея обновлений как гарантийного ремонта сама по себе не сказать, что плоха - выявили ошибки, которых в идеале вообще не должно было быть, исправили, проблема устранена. Или доработали какую-то функцию - добавили, тоже хорошо, хотя опять же, в идеале она должна была быть доработана и быть в комплекте изначально.
aik
17.01.2025 13:12Проклинаю обычно не обновления windows, а то, что они ставятся автоматом и перезагружают компьютер в неудобное время.
MaFrance351
17.01.2025 13:12Или потому что порой обновления добавляют новых багов, а не устраняют старые. Буквально каждые пару месяцев новости в духе "Новое обновление Windows 10 сломало [печать, сеть, звук, видеодрайвер, что-нибудь ещё]" или "Пользователи сталкиваются с синим экраном после недавнего обновления".
aik
17.01.2025 13:12На мой взгляд, это не массовое. Кто-то, конечно, сталкивается, но не такой уж и большой процент.
Хотя, в абсолютных цифрах, таких людей должно быть много, учитывая долю винды.
MaFrance351
17.01.2025 13:12Кто-то, конечно, сталкивается, но не такой уж и большой процент.
С отлетевшими после очередных обновлений драйверами принтера сталкивался пару раз.
Astroscope
17.01.2025 13:12Или потому что порой обновления добавляют новых багов, а не устраняют старые.
Android/iOS не сказал бы, что сильно отличаются в контексте процитированного. При этом андроиду дольно часто если не все, то многое прощают, а айоуэсники вообще выглядят сектантами, которым что наставник сказал - то они и повторяют, даже если пять минут назад говорили прямо противоположное и так же искренне в это верили. Майкрософту не прощают, и каждый прокол, а их и впрямь не сказать, что мало, становится объектом публичной порки.
Буквально каждые пару месяцев новости в духе "Новое обновление Windows 10 сломало [печать, сеть, звук, видеодрайвер, что-нибудь ещё]" или "Пользователи сталкиваются с синим экраном после недавнего обновления".
Это та самая публичная порка, о которой я говорю - нет, я не говорю, что поводы для нее надуманы. Нет, поводы для нее как раз-то реальны, но реакция общественности меня удивляет своим двоемыслием. Вы же все здесь или разработчики, или хотя бы мимокрокодилы, а не совсем случайные люди с улицы - станьте на место Microsoft и подумайте, с каким бесконечным многообразием конфигов пользовательского оборудования вашей системе приходится иметь дело. Это же просто невероятное чудо, что оно вообще хоть на трети из всего парка реальных машин хоть как-то стартует! Доля Windows среди ноутбуков и десктопов, от мелочи до рабочих станций, подавляющая. И на всех из них оно работает - конечно всегда будут такие, у которых что-то пошло не так и, если твоя доля подавляющая, больше всех остальных вместе взятых, то у тебя и процент неудач будет выше, и их абсолютное количество тем более будет выше, чем у маргинальных систем, которыми пользуется три с половиной фанатика, презирающие любую лажу и глюки. Драйвера слетают? Так а кто их пишет, кто тестирует и кто интегрирует? Не бывает ли так, что это вина разработчиков драйверов, а не самого Microsoft? Сравните это с Android, где для каждой отдельной модели телефона своя отдельная прошивка со своими одними и теми же интегрированными драйверами, которая хоть минимально тестируется на стандартном и неизменном аппаратном обеспечении - для другой модели телефона другая прошивка с другими драйверами под другую аппаратную начинку. С айоуэсниками то же самое, только еще в тысячи раз проще потому, что существующих аппаратных модификаций в тысячи раз меньше, чем андроидов. И если они в таких тепличных условиях довольно нередко лажают, то чего вы ждете от системы, которая работает не неопределенном, бесконечном наборе конфигов, и которая зависит от стороннего софта как минимум по части сторонних драйверов?
Я не пытаюсь защищать Microsoft, тем более что они лажают достаточно много для того, чтобы это просто невозможно было не замечать, только разве что если вы фанатик, который смотрит на объект своего обожания через розовые очки (привет, айфонщики - вы неправильно его держите!). Я лишь пытаюсь обратить внимание на несоразмерность сложности поддержки и несоразмерность реакции публики.
А еще... А еще принудительные и неотключаемые обновления Windows можно отключить вполне штатными средствами - да, кроме "домашней" версии. Если обновления вам объективно или субъективно нежелательны, то ваш компьютер пока что все еще ваш компьютер, хотя тенденция к стирании этой грани довольно очевидно просматривается. Все же UEFI это не заблокированный загрузчик. Все же вы пока еще администратор своей системы без необходимости странными способами получать root как в андроиде или носить, не снимая, розовые очки как в iOS.
Ну а что Microsoft перегибают палку с точки зрения навязчивости и нередко лажают с точки зрения качества обновления - так тут я не только не спорю, а наоборот одним из первых бегу поддерживать этот тезис. Мой же довольно многословный и местами чрезмерно эмоциональный комментарий только и исключительно о двоемыслии публики, обсуждающей обновления, а даже не об обновлениях самих по себе.
Astroscope
17.01.2025 13:12Проклинаю обычно не обновления windows, а то, что они ставятся автоматом и перезагружают компьютер в неудобное время.
Не подумайте, что мне самому нравится процитированное или что считаю это нормальным - и близко нет. Осуждаю как вы, осуждаю с вами, осуждаю больше вас. Но если абстрагироваться и отключить эмоции, то этот поток обновлений, нужных или нет, выглядит как (гипертрофированная) реакция разработчиков на (якобы) существующий запрос пользователей на бесконечные обновления.
DaneSoul
17.01.2025 13:12Именно так. А произойдёт это через месяц или через год - им пофиг, потому что они ничего и так не ждали.
Это если вы одни на рынке, а в реальности близкие идеи развивают разные команды разработчиков, и если ваш конкурент зацепит потенциального покупателя через месяц, то на ваш продукт через год этот покупатель возможно даже смотреть не захочет, потому как уже сидит на продукте конкурента.
muxa_ru
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Так массовый пользователь этого явным образом просил или нет?
Astroscope
17.01.2025 13:12Так массовый пользователь этого явным образом просил или нет?
Я часто слышу фразу "спрос рождает предложение". Это бред, фантазии идеалистов - что угодно, но не реальность в экономике. Я не буду касаться того, что спрос не может родить предложение, потому что не существует спроса на нечто неизвестное и не существующее. Спрос может влиять на предложение и как бы регулировать его, но это совершенно разные вещи и близкого, похожего в них примерно ничего, поэтому продолжим дальше. Предложение рождает спрос. Разработчики предложили софт - на предложение возник спрос. Высокий спрос или околонулевой - вопрос второй. Вот, имеем рынок софта, на котором есть предложение софта с т.н. аналитикой. Иногда есть предложения похожего софта без, а иногда другого вообще не предлагается. Как, по вашему, распределяется спрос, если предложений без аналитики нет вообще? Я вам отвечу, как - сто процентов потребителей софта выбирает сбор данных и слежку! Из которых понимают правила игры хорошо если доли процента. Теперь же рассмотрим случай, когда есть выбор. Что мы видим? Да по сути то же самое - потребитель ради сиюминутного удобства ставит согласие по всем пунктам лицензионного соглашения не читая его, даже если там большими буквами будет требование (и неотключаемое в настройках) продать душу Аццкой Сотоне.
Вот и ответ на ваш вопрос: массовому пользователю глубочайше безразлично и что в ситуации "жрите что дают", что в ситуации "жрите что дают или упарывайтесь в странный софт сильно не для всех", будут жрать, что дают, совершенно бездумно. Не было никакого запроса и не могло быть.
geher
17.01.2025 13:12Я не буду касаться того, что спрос не может родить предложение, потому что не существует спроса на нечто неизвестное и не существующее.
На неищвестное, конечно, спроса не будет. А вот на несуществуюшее вполне может. В том числе не только на еще несуществующее, но и на уже несуществцющее.
Другой вопрос, что этот самый спрос совсем не обязательно будет когда-нибудь удовлетворен. Причем далеко не всегда эта неуловлктворенность определяется невозможностью.
czz
17.01.2025 13:12Массовый пользователь не может просить, то есть, выставлять четко сформулированные и непротиворечивые требования, по причине отсутствия необходимой квалификации (иначе он перестает быть массовым). Поэтому решения по развитию продукта делегированы производителю, это нормально.
bak
17.01.2025 13:12Вы занимаетесь демагогией.
1) Продукт состоит из множество фичей а не из одной.
2) Большинство фичей делается чтобы массовый пользователь покупал / пользовался продуктом, но это не значит что абсолютно все фичи делаются для этого.
3) Отслеживание делается для рекламных компаний а так же для определения какими фичами люди пользуются или не пользуются. Само отслеживание пользователям напрямую не нужно. Оно нужно разработчикам чтобы: а) лучше продавать продукт, б) лучше понимать какие фичи нужны а какие нет
4) Отказ от поддержки старого железа делается когда эта самая поддержка становится убыточной (когда доход от старого железа перестаёт окупать затраты на эту поддержку).
Shaman_Ist
17.01.2025 13:12Вы занимаетесь демагогией.
1) Продукт состоит из множество фичей а не из одной.
Нижайше прошу прощения, а что такое "фича"? Ежели это задумано на будущее, то, вполне возможно. Вот только что?
Splo1ter
17.01.2025 13:12Нет. Не надо тут за всех говорить.
Как пользователь говорю, что хочу продукт с native-feel.
Не выжирающий память. Быстрый. И не отжирающий у меня время из за того, что нужен контроль DOM и всего остального ерьма присущего приложениям на Electron/Cordova.czz
17.01.2025 13:12Я тоже люблю такие продукты, которые не тормозят, запускаются мгновенно, и имеют native feel. И я уверен, что все любят.
Но также я предпочитаю продукт, который уже есть и быстро развивается, а не тот, который появится через год и будет в вечно догоняющем положении.
Кстати, когда VS code не было, рулили IDE на основе Eclipse, и вот они-то реально тормозили.
omgiafs
17.01.2025 13:12Нет.
Потому что вы покупаете говно, а потом жалуетесь. А потом снова покупаете говно.
Поэтому вам всегда будут продавать сырое говно. Потому что вы его покупаете.
И, замечу, сейчас век маркетинга. Это значит что не вы ищете то, что вам нужно, а мракетологи буквально придумывают новую хрень, агрессивно её рекламируют и все бегут её покупать, хотя и жизнь вполне счастливо прожили бы, не зная про эту хрень. Таково эволюционно обусловленное свойство нашей психики, мы восприимчивы к новому. Поэтому большинство сразу же пересаживается на 11 винду, ведь там "новое". "—А тебе конкретно что от неё нужно? —Ну, не знаю. Новое — значит лучше. —А что лучше-то? —Ой, иди на хер, душнила".
Wesha
17.01.2025 13:12вы покупаете говно, а потом жалуетесь. А потом снова покупаете говно.
Всё очень просто, следите за руками. Проблема в том, что овно везде, и высокая цена товара — вовсе не гарантия, что товар не овно — он может оказаться ничуть не меньшим овном, просто более красиво оформленным, чтобы побольше бабла с лоха срубить. А раз невозможно наперёд определить, где настоящий качественный товар, а где — дорогое овно, имеет смысл сразу покупать дешёвый товар, потому что там хотя бы убран фактор угадывания и заранее известно, что это — оно; зато когда он поломается, на сэкономленные деньги можно ещё с десяток таких же купить.
omgiafs
17.01.2025 13:12А вот не всё. Вы сами можете привести не один пример товаров, которые вас полностью устраивают.
Мой пример: Наушники Shokz OpenRun Pro. Для моего сценария использования они идеальны. Моются (потому что в них потею), беспроводные, звук хороший. Ни разу не глючили и не отваливались. До этого были Beats Powerbeats. Могу сказать что тоже очень качественный продукт. Тоже моются, тоже звук хороший, тоже не глючили.
Наушники стал приводить в пример только потому, что они первые в голову пришли. Можно и смартфоны и что угодно брать, везде есть примеры качественного исполнения не за космические, а за вполне вменяемые деньги.
Редактор Notepad++. Да, он обновляется. Да, есть баги (я не сталкивался ни с одним в моих сценариях использования). Как замена Notepad он хорош. Разве говно? Ну честно?
А теперь берём какой-нибудь импортозамещённый сервер и да, внезапно - говно. Причём кривое.
Или берём импортозамещённую систему виртуализации zVirt, читаем доку, а там написано, что API-запросы начинаются с пути/ovirt-engine
. Если честно, то так даже лучше, чем если бы сами...
Вот это и есть говно. Самое настоящее.
Итого, говно - не везде.Wesha
17.01.2025 13:12Ну так о том и речь: потому и берут дешёвое, что если овно — то потраченных денег не жалко, а если вдруг ещё и оказалось не овно — ну так вообще отлично!!!
czz
17.01.2025 13:12Нет, мы покупаем то, что помогает нам лучше решать наши задачи прямо сейчас хоть как-то.
Винда обновляется в рамках непрерывного процесса, призванного (в идеале) обеспечить у всех пользователей примерно одинаковую актуальную среду для запуска актуального ПО на актуальном железе и с актуальными обновлениями безопасности. Лично я вижу это как благо.
Этот процесс, кстати, гораздо более заметен вовсе не в винде, а среди линукс-дистрибутивов. Хотите свежее ПО из репы — ставьте новую версию дистрибутива. Да, можете продолжить регулярно собирать все новое дерево зависимостей и на старой версии, но ради чего?
Говно — понятие субъективное и относительное. Нет ничего, что в сравнении с чем-то другим (в том числе не существующим в реальности) нельзя было бы назвать говном. Вплоть до того, что все человеческое существование можно назвать говном. Поэтому предлагаю использовать более объективные оценки, привязанные к измеримым свойствам.
AlchemistDark
17.01.2025 13:12А что делать, например, школьным учителям, у которых нет денег на актуальное железо ни дома, ни на работе?
czz
17.01.2025 13:12Производитель должен заниматься благотворительностью взамен гос-ва, которому плевать на своих учителей? Нет, не должен.
Но есть много других людей, которые фактически занимаются благотворительностью, создают легковесные дистрибутивы linux, различные бесплатные open source инструменты. Ну да, они нередко работают еще хуже, чем коммерческие. Как говорится, дареному коню в зубы не смотрят.
AlchemistDark
17.01.2025 13:12А причём тут благотворительность? Или учителя это не часть рынка сбыта? И я не пишу ещё про менее развитые, чем РФ, государства.
czz
17.01.2025 13:12Ну если на них не заработать (затраты на поддержку выше прибыли), значит — не часть рынка
Areso
17.01.2025 13:12Сейчас работаю администратором некоего ПО.
ОС: CentOS 8
ПО: версия от ноября 2024, собирается и поставляется неким вендором через public repo.
Скоро будем тестить февральские сборки =)
DiegoRA
17.01.2025 13:12Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
© баш
Grey83
17.01.2025 13:12Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
максимум допилили междумордие, да и то далеко не факт: толковые программеры денег стоят, а прога уже продана и юзается, так к чему излишнии траты?
Wrench_IT
17.01.2025 13:12При чем тут программисты, если задачи и сроки ставит бизнес? А бизнес, как правило, ставит сроки "уже вчера" да еще и с прицелом на максимально возможное количество платформ (само собой, нанимать отдельные команды под десктоп, веб и мобильную разработку тоже никто не хочет), и тут уже js с обертками под разные устройства оказывается единственным реальным вариантом.
urvanov
17.01.2025 13:12считаю, что вина в этом лентяев программистов, которые словно Емеля за один месяц хотят обработать землю, посадить культуру, вырастить урожай, собрать урожай и продать урожай. Они ещё не удивляются, что 9 месяцев беременности это слишком долго и накладно?
Не программистов, а менеджеров. Именно они же сроки ставят. Да и не выпустишь сейчас, выпустят конкуренты быстрее тебя
northrop
17.01.2025 13:12считаю, что вина в этом лентяев программистов, которые словно Емеля за один месяц хотят обработать землю, посадить культуру, вырастить урожай, собрать урожай и продать урожай.
Вы попутали программистов и кабанчиков-хозяйчиков, у которых "ночь кормить - к утру зарезать" - modus vivendi везде на глобусе
Mox
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 вряд ли это будет работа на вечерок.
artptr86
17.01.2025 13:12WebPack как бы не для решения проблемы кроссбоаузерности создан и используется.
для нативной разработки требуется примерно столько же (что тогда что сейчас) сколько и для разработки на Electron
Под нативной разработкой вы подразумеваете разработку приложенмя под конкретную платформу, используя инструменты разработки конкретной платформы и её дизайн?
TrueRomanus
17.01.2025 13:12WebPack как бы не для решения проблемы кроссбоаузерности создан и используется.
Создавался не для этого, но сейчас используется в том числе и как раннер для инструментов типа AutoPrefixer, Babel и прочих которые решают эту проблему.
Под нативной разработкой вы подразумеваете разработку приложенмя под конкретную платформу, используя инструменты разработки конкретной платформы и её дизайн?
Насчет дизайна вопрос спорный но все остальное да. Вроде бы никто не мешает использовать кроссплатформенные инструменты, библиотеки, генераторы и прочее чтобы упростить себе жизнь работая больше чем на одной платформе. Приложения для Android разрабатывают не только на Java а для Windows не только на C++. Я бы даже сказал что для современных языков и фреймворков кроссплатформенность это обязательное требование, никому уже не нужен фреймворк работающий на одной платформе. Тулинг скрывает большую часть сложности на всех поддерживаемых платформах а генераторы и/или слой совместимости обеспечивает то самое пресловутое write once run everythere с оговорками естественно, но тут как бы и Electron делает тоже самое с оговорками.
artptr86
17.01.2025 13:12для современных языков и фреймворков кроссплатформенность это обязательное требование, никому уже не нужен фреймворк работающий на одной платформе
Тем не менее, по-настоящему кроссплатформенных фреймворков исчезающе мало, а «одноплатформенными» фреймворками по-прежнему продолжают пользоваться
TrueRomanus
17.01.2025 13:12Тем не менее, по-настоящему кроссплатформенных фреймворков исчезающе мало, а «одноплатформенными» фреймворками по-прежнему продолжают пользоваться
Ну хорошо вот например только для C++ кроссплатформенные либы https://philippegroarke.com/posts/2018/c++_ui_solutions/ . А еще есть много на таких языках как go и rust, некоторые поддерживают даже мобильные платформы. Вы точно уверены что их "исчезающе мало"?
artptr86
17.01.2025 13:12Большая часть из списка вымершая, к сожалению. Согласен, есть серьёзные вещи типа Qt, WxWidgets и ещё несколькиз, которые поддерживают все три десктопные платформы на хорошем уровне. А действительно хорошие на go и rust есть?
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Во-всех современных браузерах ваше приложение будет выглядеть одинаково
Во всех браузерах на одном и том же движке, вы хотели сказать? Потому что иначе ответ - конечно нет. Не так плохо как в девяностых/нулевых, но до одинаковости ещё пилить и пилить.
DarthVictor
17.01.2025 13:12Если речь идёт об альтернативах легковесному десктопному софту (то есть без WebGPU или работы с камерой), то нарваться на разное поведение даже у Хрома и Сафари сложно. Разное поведение у Хрома и Файрфокса при указнных условиях спровоцировать можно разве что специально. И нет, разные дефолтные стили на кнопках - это не разное поведение.
На мобилах ситуация чуть иная.
Но даже там маловероятно, что у вас всё приложение упадёт, может видео невоспроизвестись из-за поддержки разных кодеков. Но с этим проблема даже при использовании нативного софта отдельно под каждую платформу и она более юридического характера.
nidalee
17.01.2025 13:12Разное поведение у Хрома и Файрфокса при указнных условиях спровоцировать можно разве что специально.
У меня на одной из работ старый мак на 10.11, Firefox туда встает только ESR (что-то типа 115 против текущей 133). На нем в редакторе Хабра нельзя вставить текст из буфера обмена: только ошибки в консоли и никакого эффекта.
Grey83
17.01.2025 13:12Что ж ты как лох на старом железе сидишь: ровные пацаны давно железо/ОСь/браузер обновили и в ус не дуют.
Нет, покупай за свои, это ведь не наша проблема.ну и т.д. ит.п.
nidalee
17.01.2025 13:12Там начальство отмазывается, что новую систему поставить нельзя из-за совместимости с сервером, на котором лежат файлы. Я конечно не верю: чего там, NFS или SMB шару подключить. Но спорить мне особого смысла нет.
Grey83
17.01.2025 13:12я вообще-то про логику разрабов софта =)
nidalee
17.01.2025 13:12Да с этими-то все ясно. Уже карты сейчас будут рисовать 2+ фейковых кадра на 1 реальный, чтобы это хоть как-то пердело на топовых видеокартах. Зато в Unreal Engine можно просто галочку поставить, и вот тебе трассировка лучей.
Все для народа, правда не для того.
Grey83
17.01.2025 13:12Ну и по поводу wysiwig-редактора: я когда-то помучался с ним, когда ещё был html, а не md альтернативой, емнип, вырубил и больше не пользовался этим глючным поделием (нервы дороже).
Как md выкатили попробовал ещё раз и с тем же результатом.
Не люблю когда формочки лучше меня знают что я хочу сделать.
DarthVictor
17.01.2025 13:12Ваш Мак, судя по википедии, самое позднее 2009 года выпуска. Вы много знаете софта, которой работает на компьютерах 16летний давности? Качественный десктопный клиент первой версии Телеграма на втором Пентиуме хорошо работал?
nidalee
17.01.2025 13:12Красиво с цитатами ответить не могу: я как раз сейчас за тем маком.
Мак 2012 года выпуска (10.12.6), а конкретно 115.19.0esr вышла 7 января этого года. Что вы думаете там с версии 115 (оригинальная не-esr вышла летом 2023) до 134 поменялось так сильно, что аж скрипты отвалились? За год? Да ничего. Просто тяп-ляп и в продакшн.
DarthVictor
17.01.2025 13:12Я возможно как-то не так читаю, но на большинство маков 2012го года должны обновляться до 10.15, на котором есть последний Фаерфокс. https://everymac.com/systems/by_capability/maximum-macos-supported.html
https://support.mozilla.org/en-US/kb/firefox-users-macos-1012-1013-1014-moving-to-extended-support
А скрипты как раз обычно первыми и падают, потому что стандартна библиотека JS обновляется раз в несколько месяцев, и в сборке поддержка обычно задаётся для двух последних версий. В принципе можете попросить разработчиков хабра " включить полифилы для последнего esr". Или в свои юзерскрипты добавить полифил.
Редактор у меня и на последнем мобильном Фаерфоксе плохо работает, reach text wisywig в принципе сложен в реализации на веб-технологиях
Wesha
17.01.2025 13:12На нем в редакторе Хабра нельзя вставить текст из буфера обмена:
Дедушка
Мороз@Boomburum, хоть и не согласился сделать а-та-та своим эльфам, но всё же открыл мне секрет, как это лечится: нужно вabout:config
установить значениеlayout.css.has-selector.enabled
вtrue
— и будет Вам ЩАСТЬЕ.
Jhayphal
17.01.2025 13:12Не знаю сколько времени займёт сбор команды QT разработчиков. Но, как десктоп разработчик скажу следующее.
Сейчас 99% вакансий – веб. И лишь 1% десктоп. И, вероятно, во многом, это заслуга таких фреймворков как Electron.
И это прискорбно.
dyadyaSerezha
17.01.2025 13:12Согласен, что прискорбно, но не из-за Электрона, а из-за того, что сам софт по функционалу это на 99% веб сейчас. Увы, но такова селяви.
artptr86
17.01.2025 13:12Так даже если к универсальному аутсорсеру придёт заказчик и скажет: «Хочу приложение под Win, Lin, Mac», ему могут предложить на выбор Electron, Qt, GTK, Avalonia, Swing, JavaFX. Вроде бы ничего из современного и реально используемого на практике не забыл.
Как мне кажется, причины популярности Электрона:
последовательное игнорирование Майкрософтом Линукса в своих десктопных технологиях, иначе уже с начала 2000х у Электрона был бы мощный конкурент в виде .NET, за которым стоит крупная компания;
тяжеловесность Java Swing и приобретение Java Ораклом, который не очень заинтересован в десктопе;
относительно высокий порог вхождения в Qt (C++), медленное развитие языка до C++11 (как раз время появления Электрона);
появление Chrome (движка Blink), за которым стоит крупная компания, заинтересованная в поддержке всех современных десктопных (и мобильных) ОС, а также стабилизация Web API, появление удобных инструментов разработки (компонентные фреймворки, сборщики, база пакетов NPM, TypeScript), низкий порог вхождения в веб-технологии.
rexen
17.01.2025 13:12Подождите, а как же использование одного браузерного движка для запуска нескольких приложений? Ядро-то одинаковое. У нас же вкладки в обычном браузере шарят движковые ресурсы. Так зачем на каждое Electron-приложение запускать свой Electron? Кажется в Докере похожую проблему решили.
megahertz
17.01.2025 13:12В Linux оно так и работает зачастую. А в других ос это привычная практика каждому приложению тащить одни и те же библиотеки.
Queix
17.01.2025 13:12Приложения должны быть изолированы друг от друга. И проблема же в супер избыточности. Правильно решать именно её, а не искать какие-то косвенные пути уменьшения.
rexen
17.01.2025 13:12По-моему VScode вполне шустро работает, а значит на Электроне таки можно писать быстрые приложения. И об этом вроде бы здесь упоминали. Во-вторых, приложения и так выполняются в одной ОС, на одном процессоре, используя общие библиотеки, т.е. проблема изоляции не вчера родилась и как-то её решают. В браузерах тоже не так давно решили проблему изоляции вкладок. Собственно, чем выполнение кода разных сайтов принципиально отличается от выполнения кода разных приложений в Электроне?
NickDoom
17.01.2025 13:12А ещё дешевле и быстрее вообще вместо программистов нанять ассенизаторов. Берётся материал, быстро вылепливается интерфейс, подсушивается и выгружается у клиента. Красота! Прогресс! Или нет?
Мне надо раз было сделать быстро и красиво. Мне нарисовали дизайн — я просто его порезал на спрайты и оживил максимально совместимой версией директдров. Десять метров и работа на любом компьютерсодержащем устройстве. Скорость разработки… ну, скажем так, даже с учётом написания типа прямо аж «оконной системы» (на входе координаты клика, я сам определяю, куда клик попал) — это было просто «ни о чём». Ну чего там писать-то, чесслово? Где там рокет сайенс?
Любая красота в гуях всё равно рядом не валялась с самой простой игрушкой. Почему ж оно жрёт-то больше вдесятеро, чем движок игрушки, даже движок кроссплатформенной игрушки? Чем набиты эти фреймворки, что они столько жрут и в результате на практике используется там примерно то же самое, что уже есть в апи операционки?
TheCoolKuid
17.01.2025 13:12Мне нарисовали дизайн — я просто его порезал на спрайты и оживил максимально совместимой версией директдров. Десять метров и работа на любом компьютерсодержащем устройстве
Первая проблема - кто будет этот велосипед поддерживать?
Скорость разработки… ну, скажем так, даже с учётом написания типа прямо аж «оконной системы» (на входе координаты клика, я сам определяю, куда клик попал) — это было просто «ни о чём».
Проблема вторая - костылестроение. Никто не хочет каждый раз решать решенные задачи. Все эти фреймоврки больше про переиспользование кода. Да и в любом случае это все fun and games до тех пор пока у окон внезапно появляется сложная логика
Любая красота в гуях всё равно рядом не валялась с самой простой игрушкой.
Третья проблема - Бизнес логика. Монструозные бюрократические конвееры, где каждый инпут завязан на сотне правил, безумие писать на OpenGl, это будет неправильным построением приоритетов.
Чем набиты эти фреймворки, что они столько жрут и в результате на практике используется там примерно то же самое, что уже есть в апи операционки?
Четвертая проблема - кросплатформенность. И речь даже не о линуксе с макосями, банальная локализация может быть половина от всего кода. В стране А цифры пишутся через запятую, в стране Б шрифт содержит странные символы которые рендерятся по особенному, в стране В используют другие не арабские цифры. Достаточно посмотреть на Qt
В целом вся эта влажная мечта инженера очень быстро разбивается о бизнес реальность. В бизнесе ни у кого нет ни ресурсов ни времени заниматься нишевыми оптимизациями. Железо стоит дешево
NickDoom
17.01.2025 13:12Это всё понятно, но ведь проблемами такого масштаба занимаются коллективы размером не в один никдум… я бы тоже, естественно, второй раз не стал писать с нуля, а сделал бы из этого интерфейса что-то типа фреймворка и развивал бы его.
Почему же в ходе этого развития велосипед превращается всегда в дендрофекальную хтонь? Почему игровые движки нормальные люди могут дописать до уровня Факторио, а бизнес свои — нет?
DarthVictor
17.01.2025 13:12Почему ж оно жрёт-то больше вдесятеро, чем движок игрушки, даже движок кроссплатформенной игрушки?
Я не знаю, что именно у вас и в каком веб-приложении тормозит, но в основном, потому что для интерфейсов рисуемых и в десктопных и в веб-приложениях не существует эффективных алгоритмов аппаратной обработки. Например алгоритм вычисления размеров в каких-нибудь флекс блоках имеет хотя бы многопоточную реализацию. Особенно с учётом субпиксельног сглаживания шрифтов и разных масштабов интерфейса. Почему базовые примитивы в веб-техногологиях такие? Потому что они ориентированы на наболее корректное отображение текстов на устройствах разного размера. А на мелкие подлагивания анимации открытия менюшки там всем пофиг.
Кстати, а чем набита игра на 200ГиБ, половину из которых она ещё и наровит скачать при каждом обновлении? По сути таже причина - базовые примитивы средств разработки хреново работают с кэшированием и версионирование ресурсов, потому что интернет на десктопах у всех давно бесплатный.
Grey83
17.01.2025 13:12чем набита игра на 200ГиБ
Думаю что текстурки в 4k+, треки, видео вместо рендеринга на движке.
Обычно вот это всё занимает подавляющую часть папочки игры. Иногда это ещё и скопом запаковано в контейнеры (и если не предоставлены инструменты для работы с ними, то, помимо прочего, чтобы мододелам было сложнее изменить своими грязными ручёнками то над чем так прилежно корпели разрабы, а у мододелов монопенисуально вышло лучше, красивше и компактней) которые и обновляются целиком, вместо diff’а в том или ином виде.
artptr86
17.01.2025 13:12Для мака, линукса, айоса и андроида нет DirectDraw, придётся также поддерживать OpenGL, Metal, Vulkan.
Для линукса нет стандартной оконной системы, есть Xorg и Wayland.
У пользователя может быть переменное число дисплеев с изменяющимися настройками, в том числе с настройками масштабирования. Масштабирование может быть разным на разных дисплеях. Конфигурация может произвольно изменяться во время работы приложения.
Пользователь может вводить текст на разных языках с разными наборами символов, в том числе с диакритикой через символы нулевой ширины, смайликами, в том числе составными, а также с письмом слева направо и справа налево. В одном тексте может быть смешанное направление письма. Выделение текста тоже должно работать соответствующе.
Хоткеи клавиатуры, как правило, должны работать независимо от раскладки. Системные хоткеи могут настраиваться в системе. Да и дефолтные в разных системах — разные.
Должны поддерживаться скринридеры. На всех ОС для этого разные API. Пользователь может ходить по приложению клавиатурой, притом статические тексты тоже должны участвовать в навигации по стандартам соответствующей платформы.
Должны поддерживаться мышки, тачпады и тачскрины.
Особенности пользовательских локалей с разным форматированием уже упоминали.
Должна быть интеграция с системным буфером обмена, драг-дропом.
Диалог выбора файлов должен учитывать технические особенности и дизайн ОС.
NickDoom
17.01.2025 13:12…но ведь все эти десять пунктов можно решить за одно лето при помощи десятка экземпляров меня? О_О а у тех, кто это пишет, намного больше и квалифицированнее штаты…
Почему все эти люди не могут написать нормальный фреймворк? Хотя бы прямо вот по этим десяти пунктам подряд. От ОпенГЛ до файловых систем. Чем веб провинился, что его всюду надо тащить? Почему не пытаются, скажем, всё решить через фрезерный станок, изготавливающий каждый раз для пользователя латунную табличку?
artptr86
17.01.2025 13:12Чтобы получился ещё один аналог GTK или Qt? Менеджеры скажут: «Зачем? У нас уже есть Electron, в котором Google всё это предусмотрел»
А за одно лето десяток инженеров крупной компании даже не спроектирует фреймворк :)
NickDoom
17.01.2025 13:12Логично. Менеджерам не важно, что это кал. Им важно, что он вышел из организма Авторитетного Дяди, а из какого органа — дело десятое. Примат во всей красе, обязательное условие в большом бизнесе и политике. Мозг не нужен, нужно самое широкое красное пятно под хвостом.
PCjr, помнится, эпично пролетел. Даром что от «самой IBM». Человек разумный, в отличие от менеджера, в первую очередь интересуется продукцией, а не авторитетом испражнителя (есть одно исключение, но я о нём помолчу, а то налетит фанатьё…) А тут — народ бесится, а менеджеры реагируют вот так (не вижу смысла повторять то, что сказали лучше меня). Им-то, конечно, виднее, чем глупым пользователям /s
Поэтому в 2D-движках всё лучше на порядок. Там а) больше конкуренция, многие их пишут свои б) оценивает результат не менеджер, а разумное существо.
dpytaylo
17.01.2025 13:12Интересно, как будет развиваться тот же blitz — голый рендер HTML и CSS, без JavaScript и браузерных фич, для нативных приложений на Rust. Возможно, веб-приложения всё-таки смогут стать ещё более компактными, практически приблизившись к аналогичной производительности нативных приложений (по скорости исполнения и потреблению памяти), благодаря более совершенным подходам.
megahertz
17.01.2025 13:12Библиотеки отвечающие за построение UI на HTML с рендерингом через chromium/os webview/собственный движок стали появляться с девяностых, и сейчас их огромное количество. Но популярность совсем не та.
AuToMaton
17.01.2025 13:12Выше у DarthVictor неплохой комментарий, но хочется посмотреть с большей высоты.
Нативные десктопные приложения взаимно уничтожились в ходе войн между операционными системами в которых проиграли все. В то же время браузерные воины закончились победой Хрома и все вынуждены следовать за ним, что привело к созданию огромного количества библиотек и воцарению JavaScript. На сайтах по популярности языков складываем TypeScript и JavaScript и понимаем почему сами сайты так не делают - игра в одни ворота не интересна.
С появлением мобилок та же глупость повторилась, но тут натив уже поджидали с Web технологиями и прижали сразу, ещё и потому, что не надо было навязывать идиотские средства разработки типа пока ты ешь пиццу Gradle провернётся. Да и ценности натива вроде единообразия да профессионального дизайна подкосило под корень - такое сложно ценить когда в рамках одной личности сосуществуют KDE, macOS, Android, iPadOS и
кривой по определениюбраузер? Особенно последний. Кстати, любителям винды разрешаю, чисто из сострадания, впихнуть её в список вместо чего возжелают.Тут и стал не столько возможен сколько неизбежен Electron. Пока его привыкали ненавидеть, процесс шёл в том же направлении и теперь можно позволить себе Tauri - все родные вебвьюхи работают плюс-минус и есть WebAssembly, что выбивает из-под Flutter козырь тяжеловесности Electron. А сам Electron странно рассматривать самостоятельно, можно только вместе с Node.js и Capacitor - вот и полная кросс-платформа на единой технологии.
Хоть как-то неполная кросс-платформа ИМХО шансов больше не имеет, любая. Потому, что полных уже в ассортименте. Flutter и React Native, которых любят сравнивать и рассуждать как они меж собой бодаются, вместе движутся сейчас в неверном направлении - мимикрия под натив создаёт много проблем и даёт мало преимуществ.
У десктопного натива, снова ИМХО, был и был упущен шанс тогда, когда, с появлением Playgrounds 4 и при существовании Catalyst, разработчиков, особенно молодых, искушали забить на всё остальное и писать только под Эппл. Не случилось, у меня два объяснения - не надо было брать налог $100 с писаного на iPad и не надо было требовать забыть и про Web тоже.
Теперь будущее десктопа видится мне как сочетание замены Electron на усовершенствованных потомков типа Tauri и движения «Ясное Дело Нужно Благородно Переписать Это На Rust Прямо Сейчас», типа того же Zed. Rust, любезно подчёркиваю безопасности для - ИМХО, язык то ли глуповатый, то ли
малость садиковыйкрайне молодёжный, но имея Cargo и не имея диалектов и сборщика мусора - безальтернативный для не находивших свои мозги на помойке (это, естественно, можете считать оффтопиком и провокацией в одном флаконе).Следующий жирный шанс у нативного десктопа я ожидаю тогда, когда ИИ научится делать из
лутца водукроссплатформы натив.
IvanBodhidharma
17.01.2025 13:12Типичная программа «Hello, world» на Electron может весить более 100 МБ, что некоторые пуристы считают чудовищным.
Сегодня у меня в компе 64GB RAM, с есть 2 свободных слота, при необходимости ещё 64GB могу докинуть в любое время. Не доставил я их ещё только потому, что пока мне это решительно не надо. Мне настолько наплевать на потребление памяти электроном, что я даже не знаю. Пуристы мне напоминают тех, кто в жару летом не включает климат-контроль, экономя на бензине.
muxa_ru
17.01.2025 13:12Если не секрет, Ваша работа связана как-то с разработкой софта или веб-сайтов?
IvanBodhidharma
17.01.2025 13:12Не секрет, моя работа как-то связана с разработкой софта или веб-сайтов.
Grey83
17.01.2025 13:12Видимо потому разработанный вашей конторой софт и веб-сайты будут жрать ОЗУ и дисковое пространство без ограничений.
IvanBodhidharma
17.01.2025 13:12Подобное сообщение может написать только мудак в бессильной злобе. Когда нет аргументов, он скатывается до оскорблений. Фу, быть таким, как вы.
Grey83
17.01.2025 13:12Просто если стоит 64ГБ, то заморачиваться ради нищебродов с 4ГБ ОЗУ никто не будет (у мну было 24ГБ, но не суть).
Раз у юзверя нет бабла на нормальное железо, то и смысл морочиться ради неплатёжеспособной неЦА?
DarthVictor
17.01.2025 13:12Раз у юзверя нет бабла на нормальное железо, то и смысл морочиться ради неплатёжеспособной неЦА?
То ли дело разработчики десктопного софта только на английском языке и с кривой поддержкой скрин-ридеров...
Grey83
17.01.2025 13:12Ну насчёт инглиша - мне это не особо и проблемно. С горем пополам пойму в большинстве случаев даже без словаря.
А вот кривые кодировки - таки проблема, особенно у китайского софта (они нередко юзают какие-то свои местечковые кодировки вместо win25xx или utf-8). Приходилось пробовать переводить такой софт.
Astroscope
17.01.2025 13:12при необходимости ещё 64GB могу докинуть в любое время
Необходимость настала, вышлите мне, пожалуйста, 64GB. Пересылка за ваш счет. Вы же, надеюсь, не предлагаете мне за свой счет покупать аппаратное обеспечение для компенсации чьей-то жадности и/или рукожопости, чтобы один пишет Hello World на сто мегабайт, а условные все подстраиваются под него, за свой счет оплачивая топовые по производительности рабочие станции только потому что?
Мне настолько наплевать на потребление памяти электроном, что я даже не знаю.
Продолжайте держать нас в курсе.
Пуристы мне напоминают тех, кто в жару летом не включает климат-контроль, экономя на бензине.
Странное у вас представление о пуристах. Дело, я вас уверяю, не в экономии - какая экономия, если мотор крутится на семи-восьми тысячах оборотов и скорость у вас на прямых участках намного выше ограничителя на стоковых немецких седанах? Компрессор кондиционера естественно будет отключен, если кондиционер вообще есть - чем ближе к гонкам, тем меньше не влияющих на скорость на круге бытовых удобств, хотя цена покупки и владения лишь растет. Вы всерьез считаете, что владельцы узкоспециализированного, а поэтому точно не единственного во владении автомобиля стоимостью хорошо за сто тысяч долларов, отключают кондиционер из-за экономии бензина? Нет, вы определенно мало знаете о пуристах от мира автомобилей.
IvanBodhidharma
17.01.2025 13:12Необходимость настала, вышлите мне, пожалуйста, 64GB. Пересылка за ваш счет.
У вас русский не родной?
Вы же, надеюсь, не предлагаете мне за свой счет покупать аппаратное обеспечение
Я вам вообще ничего не предлагал. Вы кто такой? Я вас не звал.
а условные все подстраиваются под него
А условные все недееспособные? Я живу не в мире розовых единорогов, которые какают радугой и понимаю, что разработка нативного кроссплатформеного софта стоит дороже разработки его же на электроне или чем-то похожем. Если выбирать бежду наличием кроссплатформенного софта на электроне и его отсутствием, я выберу первое. Если кто-то решит таки вложиться в нативный кроссплатформенный софт, честь ему и хвала. А условные все могут не пользоваться софтом, который их чем-то не устраивает. Лично я так и делаю. Уж точно я не буду как избалованый ребёнок истерично требовать от других тратить свои деньги выполняя мои хотелки.
Продолжайте держать нас в курсе.
Продолжайте рассказывать, как вам пофиг на моё мнение и пихать мне минусов в карму. Это не лично вам, это всем отметившимся. Чем больше мн минусов наставите, тем круче вы молодцы, это ведь я личную ответственность за электрон несу, вы меня раскрыли.
Нет, вы определенно мало знаете о пуристах от мира автомобилей.
Нет, русский у вас определенно не родной. Попросите, чтобы кто-нибудь прочитал и объяснил вам моё предыдущее сообщение.
STingerOid
17.01.2025 13:12Мне в целом тоже пофиг на потребление памяти в разумных пределах (хотя у меня пока что всего 32 гига, но есть слот чтобы воткнуть еще одну планку 32), но меня напрягает скорость работы современных приложений. Вечно всякие спиннеры, ожидания неэффективных загрузок данных тысячей запросов, и это всё ещё сдобрено нафиг не нужными тормозными анимациями.
Пусть жрут память, но при этом хотя бы работают быстро.
IvanBodhidharma
17.01.2025 13:12Тот же VS Code на проектах с десятками тысяч файлов у меня не тормозит, нет спиннеров и ожиданий. И Obsidian не тормозит. Может, дело было не в бобине и не электрон тут виноват?
STingerOid
17.01.2025 13:12VS Code действительно не тормозит (хоть и запускается долго), а вот какой-нить Discord любит потупить иногда.
IvanBodhidharma
17.01.2025 13:12хоть и запускается долго
Я сейчас проверил специально, он запускается мгновенно, даже время засекать бессмысленно. Проект на 30к+ файлов из докер контейнера открылся менее чем за 3 секунды. Дискорд открылся за пару секунд, и большую часть этого времени он проверял обновления. У меня весьма средненький комп, обычная рабочая лошадка, но у меня линух. Когда сажусь за ноут сына, на котором примерно такое же железо, но винда, вот там меня тормоза бесить начинают. Так что, не в электронах дело. Скорее всего те, кто жалуются на тормоза прикладного софта просто сидят за тормозной виндой.
MaFrance351
17.01.2025 13:12Скорее всего те, кто жалуются на тормоза прикладного софта просто сидят за тормозной виндой.
Не у всех есть возможность купить себе рабочую станцию на 64 гига ОЗУ. Ещё полно машин десятилетней давности, где шесть-восемь гигабайт памяти и процессор на четыре ядра. А у тех, кто не пользуется ПК много и часто (максимум - в интернете посидеть, почту проверить, да по видеосвязи с товарищами поговорить), наверняка найдутся аппараты ещё слабее. И вот эти пользователи ощущают тормоза софта прямо всей душой.
С телефонами, впрочем, та же история.
IvanBodhidharma
17.01.2025 13:12В моём компе десятилетней давности было 32 гига. И тогда это тоже было не дорого. Я сейчас посчитал, 64 гига памяти составляют 13% от стоимости компа без видеокарты. Благо, недавно обновлял и цены помню.
Ещё раз, у вас не электроны тормозят, а винда, вы не в ту сторону воюете.
STingerOid
17.01.2025 13:123 секунды не моментально, но в целом при запуске это не напрягает, это же один раз. VS Code скорее всего быстро работает, потому что не тянет ничего по сети в процессе работы, максимум обмен небольшими данными с удалённым ssh-сервером.
И да, у меня тоже линукс.
nidalee
17.01.2025 13:12Сегодня у меня в компе 64GB RAM, с есть 2 свободных слота, при необходимости ещё 64GB могу докинуть в любое время.
У меня тоже.
Знаете, я не разработчик, но вообще считаю, что конкретно разработчиков софта нужно сажать за минимально работающую конфигурацию, чтобы едва хватало под минимальные требования ОС, на которую пишется софт. Тогда с оптимизацией дела пойдут лучше. А то, помнится, мне пришлось геймерский смартфон купить, потому что на прошлом смартфоне с 8 ядрами приложение для заказа такси (Яндекс.GO) открывалось на холодную 24 секунды (сидел с таймером).
IvanBodhidharma
17.01.2025 13:12Так а при чём тут разработчики? Задачи ставит и деньги платит бизнес.
с 8 ядрами приложение для заказа такси (Яндекс.GO) открывалось на холодную 24 секунды (сидел с таймером).
Опять же, врядли разработчики решили запихать в одно приложение карты, навигатор, заказ пиццы и такси, анальный зонд и повареную книгу со сторисами.
Nipheris
17.01.2025 13:12Давайте начистоту.
Пока Microsoft, Apple и прочие гиганты бились за звание главной платформы для запуска клиентского кода, Google тихонечко закатила всем в огород троянского коня в виде Хрома. И получилась такая вот интересная ситуация, что теперь "операционной системой" (а точнее, средой для работы клиентского приложения) является браузер, а не натив. И эта среда победила. Почему - уже написали предыдущие комментаторы.
JS и сейчас относительно конченный язык, а году в 2013-м это был ад и Израиль. И ничего, все пошли колоться об этот кактус. Чтобы писать под победившую среду запуска клиентского кода. Побежали все переписывать старые проекты - MS переписала Офис, Гугл же написал свой офис сразу в вебе.
Уже все и забыли, что "Веб" - это про организацию информации прежде всего, а не про HTML/CSS/JS.
Теперь разработчиков под нативный десктоп и нет толком. Точнее, они есть, но им за их знания заплатят намного больше, например, на бэкенде. А над клиентским десктопом можно издеваться, память-то там клиентская, она "бесплатная" для компании, в отличие от памяти на серверах.
Зато навалом разрабов под браузер, стоят они приемлемо, вот и вся история.
Вот на мобилках ресурсов поменьше, и там веба почти нет - каждый второй проект делает себе приложение и переманивает туда всякого, кто зашёл на сайт с мобилы.
А, самое главное: на десктопах толком не прижились магазины приложений. На мобилках юзеров к этому приучили с горшка, и проблема деливери/автоапдейта была решена на корню. А десктоп уже слишком стар как концепция, чтобы его юзеров можно было заставить что-то делать иначе. Microsoft Store почти никому не нужен, Snap Store тоже, разве что на Маке удалось более-менее посадить на их магаз.
Splo1ter
17.01.2025 13:12Больше скажу.
На мобилке так же пытаются пробраться кроссплатформенности в виде JS с помощью Ionic/PhoneGap/Cordova. Дешевый функционал взамен раздражению пользователей.
Резюмируя - Электрон и подобные платформы = зло.
И выбирают и выбирать будут пользователи, несмотря на какие то хромы и тп.
deema35
17.01.2025 13:12Удивительно как в современно мире все перевернулось с ног на голову. Раньше сначала писали программу, а UI был делом второстепенным. Теперь программу создают под интерфейс, именно он определяет фреймворки которые будут использоваться для написания программы.
Типичная программа «Hello, world» на Electron может весить более 100 МБ
Также это значит что приложение будет зависеть от непомерного количества программного кода. А если например какую-нибудь из библиотек перестанут поддерживать? Современный код и так переполнен зависимостями, а тут сто мегабайт зависимостей на пустом месте.
artptr86
17.01.2025 13:12Так Электрон — это практически на 100% Chromium и Node.js. Первый поддерживает Гугл, под капотом у второй — движок V8 от того же Гугла. Так что в основе платформы лежат стабильные технологии, а какие библиотеки выберет разработчик для конкретного приложения — уже его дело. Если поддержка какой-нибудь и прекратится, приложение потихоньку перепишут под другую. Главное что сама платформа стабильна и с обратной совместимостью по отношению к клиентскому коду.
Borelli
17.01.2025 13:12Стабильность Electron и приложений с автообновлением - относительная. У меня на Windows 7 перестал работать GitHub Desktop, после очередного автоапдейта. Просто выпал что не найдена dll. А её только в Windows 10 завозили. Вот такая совместимость. Пришлось найти где-то в архивах старую версию, сделать даунгрейд и вырубить обновления. Да, приложение видит, что есть новая версия. Но не чует, что новая версия не сможет запуститься на том железе/ос, какие есть.
miksoft
17.01.2025 13:12А подскажите, пожалуйста, на что посмотреть человеку, который вышел из Delphi/C++Builder и которого тошнит от JS?
Друг спрашивает...HemulGM
17.01.2025 13:12Возвращайся на Delphi и изучай кроссплатформенный фреймворк FMX, который позволяет создавать нативные GUI приложения под все платформы разом. А UI можно крутить как угодно. Из коробки выглядит "нативно", но сделать можно, чтоб выглядел как веб страница.
Alexufo
17.01.2025 13:12Если тошнит, значит он не понимает, как работает браузер.
Можно Typescript :-)
Или yewstack, если хочется веба)
falc0ner
17.01.2025 13:12Ответ зависит от того, для себя он хочет писать или зарабатывать этим как разработчик в найме. Если второе, то лучше выбирать то, что востребовано (чего пока не скажешь про тот же Tauri). Я кстати тоже вышел из Delphi, но JS вполне нравится. Непонятно, почему вашего друга так уж тошнит.
Alexufo
17.01.2025 13:12Современный фронтенд огромен и одним js не обслуживается. Это слишком другая отрасль, а здесь ты привык к своей ide шечке и компонентам за 20 лет и начинается понимание, что здесь все с нуля нужно вникать.
Учитывая спрос на webassembly плюсовикамто дорожка открыта. Сейчас даже js невезде нужен для написания сайтов.
alfangur
17.01.2025 13:12ИМХО
почти 10 лет назад сбежал из Delphi в JS
до этого на JS даже не смотрел и даже ради денег
сопротивлялся как маленький ребенок
мне хватило двух дней поиграться с JS
что бы осознать его прелесть )))
его красоту синтаксиса после Delphi
его гибкие возможности написания кода
ну и понеслось ....
радуюсь до сих пор
основной стэк:
nodejs - для back или локальных модулей
nw.js - для кросс-десктопа (аналог электрона)
ну а для UI что придется, хоть голый html и css
Борланд все просрал (((
вот реально потерянно все, что создавалось долгие годы
Эмбаркадеро вроде старался, ростил кроссплатформу
но у них как то плохо это вышло
может за последние 5 лет у них кардинально все изменилось
но проверять мы конечно это не будем )))
люблю синтаксис Delphi и его возможности
после него только JS синтаксис смог принять
все остальное будто от лукавого
Delphi хоронили долгие годы, но он как Джек Воробей - не тонет
вакансий мало или вовсе нет, но это не из-за него
а из-за современного бизнеса которому надо вчера и на все устройства сразу
ну и за две копейки конечно
спасибо TypeScript завез в JS типизацию
стало гораздо лучше писать код и понятнее
хочешь используй типизацию хочешь нет и когда хочешь дело твое
ну пусть друг посмотрит на:
python
go
rust
nim-lang
в тему про электрон
никто не упомянул nw.js - аналог электрона
опять ИМХО
работает вроде лучше чем электрон
ест меньше памяти вроде как
весь софт который я пробовал на электроне
только 5% достойны внимания - и то до конца не уверен что на электроне
остальное 95% глючная прожорливая свинья
глотает байты как дырка от node_modules
мы тут все ругаем размер готовой апликухи 150+ Мб
да это очень печально, но такая лайф
а давайте глянем на современные десктопные окружения линукса
только вчера увидел новый видео плеер который выглядит и по функционалу и юзабельности лучше имеющихся
у меня на борту КЕДЫ, а плеер хочет окружение ГНОМА
плеер на десятки Мб, а окружения ГНОМА на 750+ Мб
так что наверное в готовой апликухе увидеть 150+ Мб не так уж и плохо
если она за собой больше ничего не тянет на гигабайты
работает отлично и выполняет поставленные задачи
ну а если железо не позволяет выполнять какие-то задачи
в современном софте, то как говорится ССЗБjsre
17.01.2025 13:12Про nw.js уже было
в "Симпсонах"8 лет назад, уже тогда предрекали ему полный провал на фоне "Электрона". https://habr.com/ru/articles/304574/
Tim7456
17.01.2025 13:12Печаль - тоска в том, что забывают/игнорируют сценарии реально тяжелого использования. А на них вся эта Electron'ная чухня дохнет, сожрав предварительно всю память.
Если у тебя проект на несколько MLOC и ты открываешь по паре сотен файлов одновременно, сколько инстансов IDE ты можешь запустить одновременно? А ведь надо иногда!
В том же Хроме 2 меня тоже больше сотни вкладок открыто одновременно. Так для удобства приходится 5 инстансов Хрома запускать. И что? Он же сссамка собаки течет и падает.
А ведь когда-то это было нормальным сценарием и все работало! Вкладки в браузере в 3-4 ряда и нормально. Что-то недочитал, недоделал можно было вкладку оставить открытой и не бояться что браузер рухнет и потеряет контекст. Про падения VS вообще никто не думал что так бывает.
А сейчас приложений на JS наклепали, да только они работают по сценарию "строго 1 инстанс, не более 5 файлов разом, раз в день рестартуем ибо течет сильно". Как будто при профессиональном использовании кроме этого приложения человек ничем не пользуется и больше на машине ничего не запускает!
yrub
17.01.2025 13:12лучше так, чем никак. на сколько понимаю реальная проблем таких программ это безопасность (браузера), все остальное издержки. ради красивого и продвинутого ui я бы вполне взялся его использовать. но очевидно меру знать нужно
Gizma_2000
17.01.2025 13:12Выбрал Tauri.... Электрон пробовал, не зашло, под эмбеддед системы, когда приложуха на 2 кнопки раздувается в 200-300 мгб оперативки ... Ну совсем такое себе... А tauri спокойно такое приложение в 5-15мгб уложит... В Tauri ещё и Rust, и ещё круче становиться. Все быстро компактно, но при этом вся мощь веб -UI с тобой... не был, это все же намного лучше всякого нативного графического говна под каждую систему... Главное весь бекэнд максимально на Rust делай, а JS пусть только нужные красивости выводит и все ... Очень зашёл Tauri
HemulGM
17.01.2025 13:12Не уложит Tauri приложение в 5-15 мб оперативки. Он использует встроенные движок браузера, которые тоже - Хромиум. Tauri - это тот же Электрон, только в профиль, который просто не показывает все потребление инстанса, а скрывает его за системным потреблением.
Gizma_2000
17.01.2025 13:12Причем тут Tauri и Chromium... как раз его он не использует... Electron и Tauri это разные и по концепту и по подходам вещи... Вы теорией занимаетесь, а я с Tauri на СнК постоянно работаю, и разницу меряю сам "ручками", а не диспетчером задач, или каким-нить плагинами для линуха.... Да, да, у меня в проекте пару ядер на чистом bare-metall и я для теста, торможу/отстёгиваю ядра с linux и опрашиваю полностью память... далее сравниваю занятость до приложения, и после запуска приложения...
HemulGM
17.01.2025 13:12Tauri просто использует системный IWebBrowser (edge), в то время как Электрон его тащит с собой. Вот и вся разница. Нет никакой магии. Не обманывайтесь.
https://habr.com/ru/articles/850192/
Grey83
17.01.2025 13:12т.е. он ещё и не платформонезависимый в придачу?
HemulGM
17.01.2025 13:12Да. Работоспособность определяется именно наличием и поддержкой в системе движка веб-браузера. Функциональность, соответственно, тоже. Для каждой ОС в Tauri есть реализация WebView для фреймворка. Ну или тащится весь веб-движок с собой.
Такие приложения, кстати, были достаточно распространены раньше в Windows, потому что там всегда был встроенный IWebBrowser (IE).
Gizma_2000
17.01.2025 13:12Есть Webkit - то работаем... А он почти везде есть на 99% ( а если нет качаем наверно 100-300мб, сейчас точно не помню ))))) как обычный вес приложения на электрон))) )
Gizma_2000
17.01.2025 13:12А кто обманывается то? Вы все верно пишете - никакой магии... Есть webkit - работаем (а он почти везде есть)....Но при чем тут хромиум? И edge? Подход то другой, отсюда и существенная экономия.
HemulGM
17.01.2025 13:12Какой другой подход? На винде запускается инстанс Edge (Хромиум), в андроид - тоже хромиум. На GTK - WebKit2. В чем другой подход?
Gizma_2000
17.01.2025 13:12Т.е. вы не видите разницы между подтягиванием этого из системы, и вываливанием несколько независимых копий браузера в оперативку на каждое приложение? Т.е. если на каждую открытую в Хром страницу он будет держать в оперативке полную свою новую копию, это тоже будет одинаковый подход ?
Я нигде не говорил, что Tauri это откровение... Просто оно намного оптимальнее чем Electron. Который все проблемы решает экстенсивно, и заботиться только об уменьшении труда программиста, совершенно наплевав на пользователя. Когда калькулятор и календарь жрут как AAA игра начала 2000-ых это явно не нормально.
HemulGM
17.01.2025 13:12Вкладки весят не мало. Пусть в данном случае и опускаются суррогатные процессы хрома, только вот потребление ОЗУ от этого самой вкладкой меньше не становится.
Я не спорю, что электрон - это худший вариант, но и таури не далеко ушел. И замеры 5-15 мб не корректные. Потребление hello world приложения будут минимум 50 мб. В добавок, суррогатных процессов станет тем больше, чем больше приложений на таури запущено. Движок хромиум не всегда лишь один процесс запускает с открытием вкладки.
13werwolf13
17.01.2025 13:12В процессе своего развития Electron значительно снизил барьер для входа в сферу разработки десктопного ПО.
прекратите называть электроногавно десктопным ПО!
вебня остаётся вебнёй как её не оборачивай.falc0ner
17.01.2025 13:12Десктопное ПО - это то, которое работает на десктопе (что логично). Не важно каким образом. VS Code используют миллионы разработчиков по все миру, вряд ли его можно назвать электроногавном.
Ndochp
17.01.2025 13:12Но браузер неожиданно вместе со всеми его страницами работает на десктопе. (и на мобильнике тоже) и что теперь веб - мобильную - дескотоп разработку не разделять? Или за веб только бэк считать, который на пользовательском железе не работает (хотя может)
falc0ner
17.01.2025 13:12Забыл одно уточнение: работает на десктопе и использует API конкретной ОС. Сам браузер несомненно десктопное ПО. Приложения и страницы, что работают внутри браузера уже нет. Хотя если взять SPA-приложение, которое взаимодействует с ОС через браузер, тот тут вопрос дискуссионный, т.к. это уже близко к Electron.
Grey83
17.01.2025 13:12которое работает на десктопе (что логично). Не важно каким образом
кто сказал «виртуалки ведроида»?
JordanCpp
Идея понятна. Вместо отдельного процесса электрон с движком хрома, будет запускаться вкладка в браузере с программой. Сути то это не меняет, для того, что бы вывести на экран текст, потребуется загрузить страницу, дёрнуть js либу и т.д Грубо говоря это будет оффлайн страница.
Потому, что не будет больше у вас быстрых и маленьких программ. Вот почему ха-ха-ха
Alinaki
их не стало не потому что Electron
Andrew0610
А потому что 90 процентов пользователей в основном на мобильных устройствах?
Splo1ter
Их не стало, потому что электрон.
Нативная отрисовка в GDI+/ CoreGraphics/GTK намного быстрее, чем пресловутая загрузка js/html
Ну и возьмем другую ситуацию. Гораздо дешевле кроссплатформенная разработка. Деньги решают. Сам работал в компании, которая делала мобильное приложение на Cordova/PhoneGap с применением Angular. Это был тихий ужас. Там native-feel не пахло. Как и в приложениях написанных на Electron.
И в придачу
JS легок в изучении, в отличии от того же C++/QT, C#/WPF/Avalonia
slawkin
А почему бы не добавить разрешения как в андроиде и разрешить подключать локальным страницам, которые вы сами сделали с js скриптами доступ к файловой системе, делать запросы на сайты, подключать библиотеки операционной системы или для работы с оборудованием, чтобы можно удобно было делать программы в среде веба, а не только просмотр html или получать отклики от бекенда, на котором сайт работает..
r1000ru
Сейчас очень многое может делать браузер - взаимодействовать с файловой системой (в рамках папки, к которой вы дали доступ), ble- устройствами, webusb (программаторы), hid, камеры, даже управление сном. Чего лично мне не хватает, так это взаимодействия по голому TCP. Ну и конечно же всё это - только в хром-бэйсед браузерах. Мозилла считает всп жто опасным, а сафари в своём мире живёт.
artptr86
Filesystem API, видеозахват с камеры и WakeLock API в Файрфоксе и Сафари поддерживаются
r1000ru
Я в курсе. Мне очень не хватает Bluetooth, Serial и WebUSB API. И если пользователь мака всегда может поставить хром, то пользователи iphone - увы. Впрочем андроид тоже не поддерживает Serial API, но это легко обходится через WebUSB