Не думаю, что расходы на эксплуатацию учитывают, особенно если это не внутренний продукт.
Да и выбирают сейчас JS всё же из-за порога вхождения. К примеру WPF инструмент конечно мощный, но чтобы там сделать что-то большее чем просто конвертор температуры, нужно знатно поучиться.
Соответственно выбор в компаниях, где хотят продукт, но не хотят затрат выбор очевиден. Скайп очень показателен. Они ведь не выбрали WPF, хотя имеют в штате разработчиков знающих WPF на 5 порядочно, да и имеют средства на это.
Visual Studio Community Edition, правда на работе всё равно поставить будет нельзя. Если же использовать .net core, можно в том же VS Code. Можно в блокноте, правда с отладкой в этом случае будет не очень.
Visual Studio на базе C++ и .NET приведены просто для примера, как нечто, где есть явное сравнение. И я указал лишь для указания того, что разработчики скидывают затраты на разработку на потребителей.
Electron по определению использует webkit и никуда от него не деться и он кроссплатформенный, при этом инструменты на Java тоже кроссплатформенны и тут я соглашусь оригинальным сообщением, что всё же решения на Java меньше жрут ресурсов, чем Electron. Но тенденция показанная на базе Visual Studio наблюдается и в использовании Java.
Ну это домашний пример, домашний проект в виде хобби. При этом памяти 32Гб, но всё тормозит жутко, забил в итоге на Resharper C++.
На работе же WebStorm, плюс инструменты необходимые в работе, 8Гб, уже в притык. Есть ещё машина, где уже используется VS Code, и сопутствующее, вот там 8Гб уже не хватает в принципе. Так что да, WebStorm оптимальнее.
Но я ещё помню переход кодовой базы Visual Studio c С++ на .NET и помню повышение потребление оперативки с порядка 200Мб до 900Мб на нашем проекте. Это более показательно, разработчики ПО забивают на потребление памяти, они хотят экономить время скидывая это на потребителей.
Точно, попробуйте Visual Studio + Resharper C++ + Unreal Engine. Вот повеселитесь. Парсит исходы более получаса, почти любое действие в визуалке открывает модальный диалог с инфой о парсинге. После парсинга каждые 1-2 секунды подвисание на 2-3 секунды. Отличная работа JetBrains. На примере WebStorm, открыл пару довольно больших текстовых файла, начались лютые тормоза, проц выжран очень знатно, закрыл, а ничего не изменилось, спасает только перезапуск среды. Только не надо тут про то, что Java не умеет работать с большим объёмом текста, я как пользователь об этом знать не должен.
P.S. Если заменить Resharper C++ на Visual Assist (чем всегда и пользовался), то проблемы пропадают, парсит за пару минут, тормозов нет, функционала в основном больше. Resharper разве что ститический анализ чутка даёт. Но так как не особо он и полноценен, приходится в любом случа пользоваться иными инструментами.
Ну не у всех на рабочих компах стоит по 16Гб и больше, не надо тут говорить. На мелком проекте постоянно выжрано 2Гб+ и проц нагружен по самое нехочу, шпарит просто без остановки. Помимо VS Code надо открыть браузер, который тоже жрёт 2Гб+, надо открыть мессенджеров несколько, надо запустить webpack dev server, который жрёт 1Гб минимум. А ещё на работе стоит антивирусник, который тоже жрёт ресурся порядочно. И у меня на 8Гб постоянно всё в глубоком свапе живёт.
Вот «почему-то» хочется найти всех разработчиков использующих Electron и оторвать всё что оторвётся. Помню те времена, когда 4Гб хватало, а тут пару приложений запустил и 8Гб уже не хватает.
И какая соль? Даже поваренная соль попав в землю сделает её непригодной для сельского хозяйства на какое-то время. Так что тут разговор не о токсичности. А помимо литиевых аккумуляторов есть куча других, как-то тупо сравнивать только с ними. Есть для примера кинетические.
Да вот недавно пришлось использовать react-data-grid, я когда увидел, чего он там творит, мне стало не просто плохо, мне стало очень плохо. А он просто для табличек жестко использует абсолютно позиционированные дивы. Для каждой ячейки 3 дива и спан, в котором к моему удивлению лежит ещё один див. Я был в шоке от его скорости работы, её нет, 100 строк оно рендерит несколько секунд. Так что им норм, они не против делать непонятно что, лишь бы не использовать то, что приспособлено для требуемой задачи.
Шо, опять? Onyx, остановись, хватит штамповать по 10 моделей в год, на кой их столько? И что-то заливаете про автономность, мне кажется. Юзал 2 читалки, ну даже на неделю не хватает, при этом надо выключать полностью, а потом пару минут ждать, пока запустится. В режиме ожидания от силы на 3 дня хватало.
Да и выбирают сейчас JS всё же из-за порога вхождения. К примеру WPF инструмент конечно мощный, но чтобы там сделать что-то большее чем просто конвертор температуры, нужно знатно поучиться.
Соответственно выбор в компаниях, где хотят продукт, но не хотят затрат выбор очевиден. Скайп очень показателен. Они ведь не выбрали WPF, хотя имеют в штате разработчиков знающих WPF на 5 порядочно, да и имеют средства на это.
Electron по определению использует webkit и никуда от него не деться и он кроссплатформенный, при этом инструменты на Java тоже кроссплатформенны и тут я соглашусь оригинальным сообщением, что всё же решения на Java меньше жрут ресурсов, чем Electron. Но тенденция показанная на базе Visual Studio наблюдается и в использовании Java.
На работе же WebStorm, плюс инструменты необходимые в работе, 8Гб, уже в притык. Есть ещё машина, где уже используется VS Code, и сопутствующее, вот там 8Гб уже не хватает в принципе. Так что да, WebStorm оптимальнее.
Но я ещё помню переход кодовой базы Visual Studio c С++ на .NET и помню повышение потребление оперативки с порядка 200Мб до 900Мб на нашем проекте. Это более показательно, разработчики ПО забивают на потребление памяти, они хотят экономить время скидывая это на потребителей.
P.S. Если заменить Resharper C++ на Visual Assist (чем всегда и пользовался), то проблемы пропадают, парсит за пару минут, тормозов нет, функционала в основном больше. Resharper разве что ститический анализ чутка даёт. Но так как не особо он и полноценен, приходится в любом случа пользоваться иными инструментами.
Да ну? Уже были «гибкие» девайсы. Да и обилие брака для данной компании в порядке.
Если уж писать подобную статью, то нужно как минимум сравнение с другими решениями, учитывая, что есть куда известнее и популярнее.