Какие преимущества у C# и недостатки перед JS (Electron, NW.JS) для дескстопных приложений?

Question

[ldmitriy]

Что бы выбрали, что удобнее?
Пишут сейчас вообще локальные приложения ?

Comments

[Толстый Лорри]

Кроличья нора глубже, чем вам может казаться. Вы пытаетесь сравнивать языки или платформы?

Для того, чтобы писать десктопный софт на JS может быть всего две родственных причины:

1. вы хотите мигрировать интерфейс сайта в новую программу
   
2. у вас в распоряжении есть только веб-фронтендеры
   

В остальных случаях стоит выбрать Qt.

Answer 1

[beduin01]

Electron корявое и глюкавое поделие. Дальнейшее обсуждение бессмысленно.

Comments

[sim3x]

Артём Петренков, те для того чтоб сделать из него что-то вменяемое требются ресурсы и напряжение такой корпорации как МС

[Griboks]

Артём Петренков, на столько, на сколько интерфейс минус системное api для js.

[sim3x]

Артём Петренков,
Вполне всей

Причем у одних отделов получается, а у тех что пилят скайп - нет

Кроссплатформенное - ни на чем

Потому, как платформы разные и подходы у них различаются, так что общая кодовая база стремится к 0

[sim3x]

Артём Петренков, Легкое противоречие есть, да

UI/IX диктует бизнесс логику, взаимодействие на десктопе и на среднем мобайле - сильно отличается, и отличается от планшета, и отличается от презентации на мониторе

Если в приложении больше 4х рабочих кнопок - его нельзя сделать хорошо под все платформы в одной среде

[Толстый Лорри]

Артём Петренков, затраты сравнимые, но эффект разный. VS Code тормозной в сравнении с аналогами, как ни крути, а популярность снискал не благодаря электрону под капотом.

Вообше, это странно, когда как пример великолепного приложения на JS приводят текстовый редатор на стероидах. Ничего крупнее не сделали?

Answer 2

[Виктор П.]

JS код всегда запускается в какой-то обёртке, которая позволяет выполняться этому коду на платформе. По сути, этот код может работать только с теми методами, которые отдаёт обёртка, то есть, с каким-то функционалом js код в принципе не сможет работать. Второе, так как вызовы идут через эту прослойку, всё работает медленнее. И может выдавать иногда неожиданные результаты.
Когда вы пишете на компилируемых языках (например, c#), то вы обращаетесь напрямую к используемой системе, можете работать без ограничений и без неожиданных результатов (и быстрее)

Comments

[Толстый Лорри]

Когда вы пишете на компилируемых языках (например, c#), то вы обращаетесь напрямую к используемой системе

Окститесь, C# компилируется в байт-код, который выполняется виртуальной машиной (CLR).

[Виктор П.]

Толстый Лорри, можно так, можно так. Тут не особо понятно из условий что собираются делать.
В любом случае, clr это немного другая вещь, более низкого уровня и сравнивать эту "виртуальную машину" с обёртской скажем, апач кордова, которая на яваскрипте некорректно. В кордове можно использовать только то api, которое даёт кордова. Когда вы пишете на c#, у вас больше возможностей.
Про натив код первых пару ссылок с гугла:
https://habr.com/company/microsoft/blog/265889/
https://docs.microsoft.com/ru-ru/dotnet/framework/...

[Толстый Лорри]

Виктор П., .NET Native - по сути, AOT-компиляция в натив (что играет роль только на холодном старте), рефлекшн при этом будет так же тормозить и мы лишимся рантаймовых оптимизаций.

Я бы топил за байт-код, который куда лучше оптимизируется и быстрее парсится, чем текстовый (!!!) аналог. Типизацию, пользовательские ValueType'ы и все вот это вот.

В кордове можно использовать только то api, которое даёт кордова. Когда вы пишете на c#, у вас больше возможностей.

Вы точно так же используете API фреймворка и CLR. Есть некоторое читерство unsafe, но это почти всегда будет вынужденной мерой, уж точно не лучшей практикой, используемой повсеместно. Но кордова может подключать нативные "плагины".

[Виктор П.]

Хм, спасибо за участие. Из первого абзаца я много чего не понял и полез ковырять интернеты. До рантаймовых оптимизаций я не дошел, что это?
Рефлексии вообще полностью вырезаются, их нельзя использовать, они заменяются статическим связыванием.
Я раньше думал, что если мы на выходе получили байт-код, то его выполнением занимается уже не CLR, мы избавились от всей .net framework-овской обвязки и .net core по такому же принципу может компилироваться под разные платформы.

Про CLR, можете прояснить этот момент:

.NET Native заменяет полную среду CLR на оптимизированную среды выполнения, которая в первую очередь содержит сборщика мусора. Оптимизированная среда выполнения находится в библиотеке mrt100_app.dll, которая является локальной для приложения и имеет размер только несколько сотен килобайт. Это возможно потому, что статическое связывание устраняет необходимость во многих операциях, реализуемых средой CLR.

То есть я вижу, что CLR остается, хоть и в урезанном виде. Получается, в классическом варианте, эта среда сначала транслировала промежуточный язык в байт код и выполняла его. А в .net native она остается, но просто выполняет байт код?

Мне кажется, что у меня какая-то не полная картина мира
Вот наиболее полная статья, которую сегодня просматривал:
https://docs.microsoft.com/ru-ru/dotnet/framework/...

Answer 3

[McRain]

Прежде всего - используйте то, что знаете лучше.
Все остальное - вторично.
У C# возможностей по работе с локальными рестурсами больше чем у JS.
Electron, NW.JS были придуманы от отсутствия C# программистов но наличия js-разработчиков ))