Electron

원명 Atom Shell.

Electron 28부터, ESM을 지원합니다.

참고: https://github.com/Elanis/web-to-desktop-framework-comparison

NW.js(원명 node-webkit)는 Electron의 주요 경쟁자로, 둘 다 Chromium+Node.js 아키텍처의 크로스 플랫폼 데스크톱 애플리케이션 솔루션입니다.
NW.js는 Electron보다 2년 먼저 출시되었지만, Electron이 이제 NW.js보다 훨씬 인기가 많으며, 앞으로도 이 상황이 바뀔 가능성은 낮습니다.

Electron은 메인 프로세스와 렌더러 프로세스를 분리했습니다.
렌더러 프로세스 내는 두 개의 컨텍스트로 나뉘어 있으며, 각각 Node.js 코드와 브라우저 측 코드를 실행합니다.

Electron 모델은 관심사를 분리했지만, 이러한 강제적인 관심사 분리 설계가 의미가 있는지는 매우 논쟁의 여지가 있습니다.
이상할 정도로 번거로운 IPC 설계와 끊임없는 보안 연출은 개발 경험을 매우 나쁘게 만듭니다.

NW.js는 Chrome 앱 아키텍처를 기반으로 하며, Node.js와 Chromium 렌더러가 동일 프로세스를 공유하므로 브라우저 측에서 Node.js 모듈을 직접 사용할 수 있습니다.
브라우저 측에서 Node.js 네이티브 플러그인을 직접 로드할 수 있으므로, NW.js의 성능은 IPC에 의존하는 Electron 및 WASM 기반 솔루션보다 훨씬 우수합니다.

컨텍스트 분리 모드와 혼합 컨텍스트 모드 두 가지가 있습니다:

컨텍스트 분리 모드에서는 Node 컨텍스트와 Web 컨텍스트 두 환경으로 나뉘며, Node 컨텍스트는 Node.js 모듈의 실행 환경이고, Web 컨텍스트는 NW.js 스크립트의 실행 환경입니다.
다른 컨텍스트의 전역 변수가 격리되어 있으므로, 참조 동등성 문제가 발생하기 쉽습니다.
혼합 컨텍스트 모드에서는 하나의 컨텍스트만 사용합니다.
참조 동등성 문제는 발생하지 않지만, 서드파티 라이브러리에 의해 컨텍스트가 오염될 위험이 있습니다.

Electron의 진입점은 메인 프로세스의 JavaScript 스크립트입니다.
NW.js의 진입점은 주로 HTML 파일이지만, JavaScript 스크립트일 수도 있습니다.

Electron의 문서는 NW.js의 문서보다 훨씬 우수하며, 후자의 문서는 가독성이 떨어지고 업데이트가 심각하게 부족합니다.

Electron은 네이티브 소스 코드 보호 기능이 없으므로, bytenode 또는 electron-vite와 같은 V8 바이트코드 솔루션을 사용해야 합니다.
NW.js에는 공식적으로 제공되는 코드 컴파일러 nwjc가 있으며, 원리는 bytenode와 동일하지만 구현은 약간 다릅니다:
NW.js는 V8을 직접 수정할 수 있으므로 bytenode와 같은 외부 솔루션이 가지는 많은 제약 사항을 피할 수 있습니다.

Electron은 많은 상업 회사 사용자를 보유하고 있으며, 가장 유명한 프로젝트는 VSCode입니다.
NW.js는 일찍 시작했지만, 현재 사용자 수가 비교적 적습니다.
RPG Maker로 제작된 게임은 NW.js의 현재 가장 큰 사용자 소스일 수 있습니다.

Neutralinojs는 Chromium을 패키징하지 않고, 운영 체제의 WebView를 사용합니다.
WebView는 예상대로 호환성 문제를 야기하므로, 프로덕션 수준의 솔루션으로 고려되지 않습니다.

Neutralinojs는 구형 Windows 시스템을 지원하지 않습니다: https://github.com/neutralinojs/neutralinojs/issues/486

Tauri는 Rust와 운영 체제의 WebView를 사용하며, Node.js 모듈을 지원하지 않으므로 Rust로 API를 작성해야 합니다.
WebView는 예상대로 호환성 문제를 야기하므로, 프로덕션 수준의 솔루션으로 고려되지 않습니다.

데스크톱 플랫폼 외에도, Tauri는 iOS와 Android도 지원할 계획입니다.

컨텍스트 격리는 불필요한 복잡성을 만듭니다.
API의 통일성이 부족하며, 창의 메뉴바를 제거하는 방법만 해도 여러 가지입니다.
너무 빠른 메이저 버전 반복 전략.
유용한 테스트 프레임워크가 부족합니다.

Electron 애플리케이션의 메인 프로세스로, 전체 애플리케이션의 진입점이며, 하나의 인스턴스에 하나만 존재할 수 있습니다.

Electron 애플리케이션에서 사용자 인터페이스를 담당하는 프로세스로, 메인 프로세스에 의해 시작되며, 하나의 인스턴스에 여러 개가 있을 수 있습니다.

렌더러 프로세스는 기본적으로 네이티브 Node.js 모듈에 직접 접근할 수 없으며,
모든 Node.js 모듈은 preload 스크립트에 의해 생성된 컨텍스트 격리 인터페이스를 통해 간접적으로 호출되어야 합니다.

창 생성 시 nodeIntegration: true 옵션을 통해 렌더러 프로세스의 Node.js 통합을 활성화할 수 있습니다.

기본적으로, preload 스크립트와 렌더러 프로세스의 호스트 환경은 격리되어 있으며,
둘은 오직 =contextBridge=와 =window.postMessage=를 통해서만 통신할 수 있습니다.

=contextIsolation: false=를 통해 이 동작을 취소할 수 있습니다.

=contextBirdge.exposeInMainWorld=는 preload 스크립트에서 렌더러 프로세스의 호스트 환경에 API를 노출하는 유일한 방법입니다.

브릿징 시 사용 가능한 데이터 유형에 제한이 있습니다:
기본적인 구조화 가능한 클론 유형 외에도, 함수, Promise, Error 등의 객체를 보낼 수 있지만, 여전히 일반적인 요구 사항을 충족시키지 못합니다.

브릿징은 다음 특성도 가집니다:

preload의 경우, API 노출은 일회성이므로 반복해서 노출할 수 없으며, API 변경 사항이 호스트 환경에 동기화될 수도 없습니다.
호스트 환경의 경우, 원격 함수 내부에서는 native code로 표시됩니다.
노출된 객체는 동결되므로, 호스트 환경에서는 API를 쓸 수 없습니다.
지원되지 않는 유형의 경우, =undefined=/객체 속성 복사/오류 발생이라는 세 가지 다른 결과가 나타날 수 있습니다.

renderer 프로세스는 ipcRenderer를 사용하여 main 프로세스에 요청을 보낼 수 있습니다.

이 ipc는 두 가지 모드를 지원합니다:

send: ipcMain에 메시지만 전송
invoke: request-reply 모드

컨텍스트 격리 때문에 renderer 프로세스에서 =ipcRenderer.send/invoke=를 호출하는 것이 매우 불편합니다.

main 프로세스는 renderer 프로세스에 요청을 보낼 수 있지만, 먼저 renderer 프로세스의 WebContents 객체를 얻어야 합니다.

WebContents 객체를 얻는 두 가지 방법은 다음과 같습니다:

renderer가 먼저 main에 요청을 보내면, main이 받는 =event.sender=가 WebContents 객체입니다.
main이 창 생성 시 BrowserWindow를 보관한 다음 =BrowserWindow.webContents=를 사용합니다.

컨텍스트 격리 때문에 renderer 프로세스에서 이벤트 리스너를 등록하는 것이 매우 불편합니다.

표준 MessagePort 인터페이스.
https://www.electronjs.org/docs/latest/tutorial/message-ports

main과 renderer, renderer와 renderer 간 통신에 적합합니다.
main과 renderer는 ipcMain과 ipcRenderer를 통해 통신할 수 있으므로,
이 통신 방식은 주로 renderer와 renderer 간 통신에 사용됩니다.

통신을 설정하기 전에 먼저 ipcMain과 ipcRenderer를 통해 MessagePort 객체를 전달해야 합니다.

네트워크 프로토콜을 통해 IPC를 구현할 수 있습니다. 예를 들어 HTTP 및 WebSocket.

Electron에서 Main과 Renderer(Web 컨텍스트) 간 통신을 설정하는 것이 매우 번거롭다는 점을 고려할 때,
네트워크 프로토콜 기반을 IPC로 사용하여 복잡성을 줄이는 것도 한 가지 방법입니다.

IPC 인터페이스가 동일 네트워크의 다른 프로그램에 노출됩니다.
성능이 다른 방법보다 떨어집니다.

ABI가 다르기 때문에 Electron은 Node.js의 네이티브 모듈을 직접 사용할 수 없으며, 모듈은 Electron 전용으로 컴파일되어야 합니다.

https://www.electronjs.org/docs/latest/tutorial/devtools-extension

Electron은 Chrome 확장 프로그램 API를 제한적으로 지원하며, 일부 개발 도구를 로드할 수 있습니다.

Windows 및 macOS에서 Electron 자체 API는 시작 시 자동 실행 설정을 위해 사용할 수 있습니다:
https://www.electronjs.org/docs/latest/api/app#appsetloginitemsettingssettings-macos-windows

그러나 관련 기능의 구현은 다음과 같은 비극적인 버그로 가득합니다:

https://github.com/electron/electron/issues/32657
https://github.com/electron/electron/issues/33308

이 구현은 사용자 정의 args를 지원하지 않습니다.

설정 항목을 JSON 파일로 영속화하는 데 특화된 솔루션.
내부적으로 동일 저자의 conf 모듈을 사용하며, JSON Schema 및 package.json 기반 버전 마이그레이션을 지원합니다.

메모리에서 실행되는 문서 데이터베이스로, 주기적으로 파일 시스템에 영속화됩니다.

개발이 활발하지 않습니다.

순수 JavaScript 모듈로, JSON을 데이터베이스로 사용합니다.

이것은 본질적으로 JSON을 읽고 쓰는 클래스일 뿐이며, 특별한 점은 없습니다.

작성자가 유지 보수를 중단했습니다.

RxJS와 PouchDB를 결합한 고급 데이터베이스.
PouchDB 생태계를 사용하므로, Electron을 공식적으로 지원합니다.

다운로드 수와 Github Stars 수가 비례하지 않는 전형적인 사례로, 실제 사용자 수는 많지 않습니다.
작성자가 이 프로젝트에 많은 노력을 기울였음에도 불구하고, 이 프로젝트는 신규 사용자에게 여전히 가파른 학습 곡선을 제공합니다.

이 프로젝트는 또한 작성자가 제어할 수 없는 너무 많은 패키지에 의존하여 매우 취약합니다:

RxJS
PouchDB
pouchdb-find(RxCollection의 find 메서드는 이 패키지를 직접 사용하므로 동일한 결함을 공유)
mquery(코드를 복사함)

v10 버전부터 RxDB는 PouchDB에서 벗어날 준비를 시작했습니다.

프로젝트의 인기도, 유지 보수성, 종속성의 신뢰성 측면에서 RxDB는 사용할 가치가 없습니다.

Node.js에서 PouchDB는 levelup 모듈을 통해 LevelDB를 저장소 하위 계층으로 사용합니다.
levelup 모듈의 하위 계층은 네이티브 모듈이지만, Electron을 기본적으로 지원하므로 electron-rebuild로 처리할 필요 없이 사용할 수 있습니다.

PouchDB는 다중 프로세스 시나리오를 위해 설계되지 않았으며, 많은 메모리 기반 최적화 기능이 있고, Node.js 하위 계층 LevelDB도 다중 프로세스를 지원하지 않습니다.
따라서 Electron에서 사용할 때는 Main 프로세스에서만 인스턴스를 생성하고, IPC를 통해 Renderer에 노출하여 접근해야 합니다.

pouchdb-find는 Mongo 스타일 쿼리 구문을 구현하기 위한 공식 확장입니다.

이 패키지에는 다음과 같은 많은 문제가 있습니다 (제한적이지 않음):

인덱스가 있는 경우 오히려 올바른 결과를 얻지 못함:
https://github.com/pouchdb/pouchdb/issues/7810
관련 이슈는 닫혔지만, 저는 v7.2.2 패키지에서 동일한 문제를 경험했습니다.
선택기 누락:
https://github.com/pouchdb/pouchdb/issues/6572
https://github.com/pouchdb/pouchdb/issues/6371

이 패키지에 의존한 쿼리는 분명히 신뢰할 수 없습니다.
Mongo 지원 없이는 PouchDB는 사용할 가치가 없습니다.

이전 버전은 2020년에 출시되었으며, 그동안 버그가 수정되지 않았고, 많은 중요한 버그 이슈가 유지 보수자에 의해 무시되었습니다.
그 유형 정의 =@types/pouchdb=도 구형입니다 (PouchDB v6.4에 맞춤).

RxDB의 작성자도 RxDB v10 출시 노트에서 PouchDB가 제대로 유지 보수되지 않는다고 언급했습니다.

https://github.com/pouchdb/pouchdb/issues/3224

Node-API(N-API)를 지원하지 않는 네이티브 모듈인 better-sqlite3는
electron-rebuild로 처리해야 사용할 수 있으며, 이는 종속성 잠금 문제를 야기할 수 있습니다.

이것은 Ghost 팀이 유지 보수하는 SQLite3 모듈입니다.
이 모듈은 v5 버전부터 Node-API 기반으로 재작성되었습니다.

콜백 인터페이스는 this를 설정하여 화살표 함수를 사용할 수 없게 만듭니다.

Promise 래핑을 얻으려면 서드파티 래퍼 node-sqlite를 설치해야 합니다.

이 라이브러리의 각 Database 인스턴스는 하나의 연결일 뿐이며, 경쟁 조건은 존재하지 않습니다.
트랜잭션이 시작되는 동안 인스턴스에서 실행되는 모든 문은 해당 트랜잭션의 일부가 됩니다.
따라서 트랜잭션을 시작하려면 항상 새 인스턴스를 생성해야 하며, 인스턴스를 재사용하려면 풀을 생성해야 하므로 솔루션이 복잡해집니다.

이것은 VSCode에서 사용하는 SQLite3 라이브러리로, sqlite3의 포크입니다.

https://www.electronjs.org/docs/latest/tutorial/application-distribution

본질적으로 애플리케이션 배포는 특정 디렉터리 구조를 만족하는 사전 빌드된 Electron 바이너리 패키지를 배포함으로써 이루어집니다.
예를 들어, Windows에서 수동 배포 방법은 해당 버전, 해당 플랫폼의 사전 빌드된 Electron 바이너리 패키지를 다운로드하고,
Electron 디렉터리에 resources/app 디렉터리를 생성한 다음 전체 프로젝트 파일을 이 디렉터리에 복사하는 것입니다.
그 후, 일반적으로 Electron 실행 파일의 이름 변경 및 아이콘 변경이 필요합니다.

공식 electron-packager 패키지는 위 단계를 간소화하는 데 사용될 수 있습니다.

Electron 전용의 tar와 유사한 파일 형식으로, Electron 프로젝트를 단일 파일로 패키징하는 것을 목표로 합니다.
resources/app.asar 파일은 resources/app 폴더를 대체할 수 있습니다.

일부 네이티브 모듈은 asar 파일로 패키징된 후 이 오류를 발생시킵니다.
asar 패키징을 사용하지 않는 경우, Electron은 네이티브 모듈을 올바르게 찾고 로드할 수 있습니다.

~--asar.unpack=*.{node,dll}~를 electron-packager의 --asar 대신 사용하면 이 문제를 해결할 수 있습니다.

참고:

https://github.com/electron/packager/issues/424
https://github.com/electron/asar/issues/75

=app.isPackaged=는 Electron 애플리케이션이 개발 환경에 있는지 프로덕션 환경에 있는지 판단하는 데 널리 사용됩니다.

그러나 이 판단 방식은 다소 직관적이지 않습니다. Electron 실행 파일의 파일 이름이 여전히 electron인지 확인하는 방식으로 이루어집니다.

이 패키지는 각 플랫폼용 애플리케이션 생성을 자동화하는 데 사용됩니다.

실행 파일 아이콘 설정을 지원합니다.
devDependencies를 삭제하여 패키지 크기를 줄이는 것을 지원합니다.

electron-packager는 ignore 파일에 따라 패키징 경로를 무시하는 기능이 부족합니다. 한때 .electronignore 파일에 대한 PR이 있었지만 거부되었습니다
(거부 이유는 논리와 사실적 근거가 부족했습니다).
이 기능이 부족하면 electron-packager는 쓸모없는 패키지가 됩니다. 왜냐하면 명령줄에 ignore 매개변수를 많이 추가하지 않는 한 개발 환경도 함께 패키징되기 때문입니다.

이 프로젝트는 --all 옵션을 활성화할 때 I/O 및 CPU 리소스 사용량이 수행하는 작업에 필요한 수준보다 훨씬 높습니다.
소스 코드를 확인한 결과, 이 프로그램은 모든 작업을 병렬로 처리하며, Electron v28에서는 동시에 10개의 Electron을 다운로드하는 것을 의미합니다.
서버 대역폭과 다운로드 측의 대역폭을 고려할 때, 이러한 무분별한 병렬 처리는 네트워크 오류 발생 확률만 높입니다.

Windows 설치 프로그램의 오픈 소스 솔루션.

electron-builder에 의해 지원됩니다.

커뮤니티 패키지 electron-wix-msi에 의해 지원됩니다.

Windows 8부터 지원되는 UWP 형식으로, Microsoft Store에 게시할 수 있습니다.

electron-builder는 MakeAppx 도구를 사용하여 프로그램을 appx로 패키징할 수 있습니다.

Microsoft가 2018년부터 지원하는 주요 형식으로, MSI를 대체하고 Windows 10 이상 시스템에 사용되며, Microsoft Store에 게시할 수 있습니다.

Electron 커뮤니티에는 아직 MSIX 패키징 솔루션이 존재하지 않습니다.
패키징 솔루션 제공업체 Advanced Installer는 Electron 프로젝트를 MSIX로 패키징하는 것을 지원합니다.
Microsoft 공식 제공 MSIX Packaging Tool은 EXE 또는 MSI 설치 프로그램을 MSIX로 다시 패키징하는 데 사용할 수 있습니다:
https://docs.microsoft.com/en-us/windows/msix/packaging-tool/create-app-package

Electron에는 ChromeDriver 기반의 공식적으로 유지 보수되는 테스트 라이브러리 Spectron이 있었지만, 유지 보수자 부족으로 2022년 초에 더 이상 사용되지 않게 되었습니다.

Spectron의 잠재적인 대체 솔루션은 Playwright입니다.
그러나 Playwright v1.16 현재, Playwright 기반 테스트는 여전히 실험적인 기능이며 대부분 사용할 수 없습니다:

오류를 디버깅할 수 없습니다.
evaluate는 Node.js 모듈 가져오기를 지원하지 않습니다.

창 오버레이를 생성하는 라이브러리.

Electron 프로그램의 통합 개발 및 패키징.

Electron 프로그램의 통합 패키징 및 배포.

문서가 비극적일 정도로 일관성이 없습니다.

Electron은 Node.js와 다른 버전의 ABI를 사용하므로, npm과 yarn이 현재 Node.js 버전을 대상으로 다운로드한 네이티브 모듈을 직접 사용할 수 없습니다.
electron-rebuild는 이 문제를 해결하기 위한 도구입니다.

유지 보수성 측면에서 electron-rebuild가 필요한 네이티브 모듈은 사용하지 않는 것이 좋습니다.

electron-rebuild는 올바른 ABI 버전을 선택할 수 없으므로, electron-rebuild에 의존하는 모듈은 업그레이드하기 어려운 종속성으로 발전할 수 있습니다.
https://github.com/electron/electron-rebuild/issues/886
공식 저장소에 속하지만, electron-rebuild는 종종 Electron의 최신 버전을 따라가지 못합니다.