Цель кроссплатформенной среды — предоставить разработчикам достаточную абстракцию среды выполнения для написания приложений для набора разнородных сред с меньшими усилиями, чем для написания собственных приложений для этих сред по отдельности.
Какой смысл использовать фреймворк, который убирает нативные API, если вам просто нужно вкладывать средства в создание собственных нативных интерфейсов? Если вам нужно было написать значительный объем кода, чтобы добавить нативную функциональность, то это был не тот кроссплатформенный фреймворк.
Действительно, если вы видите описание на сайте Electron:
Узнайте, как обернуть свое веб-приложение с помощью Electron, получить доступ ко всем API и создать установщики.
Electron предназначен для веб-приложений. Для того, чтобы обернуть их в оболочку настольного приложения, которую пользователь может запускать независимо от браузера пользователя, что дает вам более жесткий контроль над поддерживаемыми вами браузерами и взаимодействием с пользователем. И веб-приложения, работающие в браузере, не должны иметь тесную интеграцию с платформой пользователя, поэтому вы не должны ожидать этого от Electron.
Построить на правильном фундаменте для структуры, не так ли? Если ваша пользовательская база слишком сложна для веб-приложения, тогда выберите фреймворк, который предоставляет им нативный опыт, который они предпочитают, в абстракции, которой могут воспользоваться ваши разработчики. По сей день это остается родной структурой поставщика для их платформы, подключенной к серверной части C++.
Слишком хардкор для вашей команды? Затем используйте Spring и Java, которые далеки от совершенства, но все же обеспечивают лучший рабочий стол, чем Electron.
