Electron vs WPF

hooeee·2023년 12월 22일
JavaScriptReactelectron

Javascript

목록 보기
1/1
post-thumbnail

환경

  • Window OS, StandAlone App
  • React (18.x.x)
  • electron (28.x.x)


Electron 도입기

다음과 같은 환경에서 서비스될 Desktop App 신규 개발 건이 들어 왔다. WPF와 Electron을 두고 그간 WPF로 개발하면서 느낀 불편함이 떠올라 Electron을 도입하게 되었다.



도입하게 된 계기

  • Wpf의 불편함..
  • NPM의 모든 라이브러리를 채택 할수 있다.
  • 웹개발자 였다면 러닝커브가 제로!! (HTML + Node js)
  • 방대한 커뮤니티 (HTML, CSS, NodeJs로 소통 가능한 모든 자료를 사용 할 수 있다.)

도입 계기중 가장큰 비중은 방대한 커뮤니티와 NPM라이브러리가 가장 크다.



WPF 뭐가 불편하길래..?

  • Desktop App 개발의 수요가 점차 줄어듬에 따라 자료검색, 이슈처리등에서 신속하지 못했다.
  • Xaml의 러닝커브
    • WPF 프로젝트를 다 년간 진행해 보았지만, 아직도 Xaml의 Style Code는 익숙하지 않다... HTML과 다르게 Xaml의 Style코드는 Command, Element Key를 이용하여 데이터의 흐름도 제어 할 수 있다. 그리고 상속 관계에 있는 Component 이하, UseControl에 대한 처리도 가능하기때문에 여간 복잡한게 아니다. Xaml 자료는 있어도 Xaml Style 자료는 정말 찾기 힘든 실정..

위에서 말하는 상속 관계가 단순히 Css의 아래와 같은 관계는 아니다.
Html의 경우 MarkUp업으로 단순 계층화된 텍스트에 지나지 않지만, WPF는 컴파일되는 실제 객체의 상속관계를 띄고 있어서 더 욱 어려운 Style 선언이 이루어 진다..

<!-- css -->
.container {
   background : '#ff0';
   margin : 6px;
}
.container > div {
   color : '#ff0'
}

<!-- Xaml Style -->
<Style x:Key="WindowHeader" TargetType="DockPanel" >
    <Setter Property="Background" Value="AntiqueWhite"></Setter>
    <Style.Resources>
        <Style TargetType="Image">
            <Setter Property="Margin" Value="6"></Setter>
        </Style>
        <Style TargetType="TextBlock">
            <Setter Property="FontColor" Value="#ff0"></Setter>
        </Style>
    </Style.Resources>
</Style>

(위 두 코드는 같은 Effect를 발생하는 Css, Style Code 이다

위와 같은 실정으로 WPF는 현재 상용라이브러리에 의존하고 있는 실정이다. 개인 프로젝트에서 700달러나 하는 상용라이브러를 쓰는것은 부담이 크다. 무료 라이브러리도 있지만 결국 일 부분은 직접 Style을 수정해야한다는 부담이 따른다..



그럼 Electron은 문제가 없었나?

문제는 언어의 태생에 있었다.

javascript는 태생적으로 Browser에서 작업을 처리하기 위한 형태로 진화해 왔고 C#은 Window OS 친화적인 언어라는 태생을 가지고 있다. 지금이야 NodeJs도 Express, Nest와 같은 Framework가 많이 개발되면서 차츰 이런 모습이 퇴화되고 있지만, 태생부터 C#은 native Code로 Window 자원을 가져오는 것에 제한이 없다. javascript의 경우 브라우저 단에서 클라이언의 자원을 가져오는 것이 엄격히 금지되어 왔고, Nodejs가 오랜기간 군림하고 있음에도 클라이언트의 OS자원을 가져오고 처리하는것에는 다른 언어, 프레임워크의 third party의 의존하고 있는 실정이다. (보통 python Module을 내부적으로 돌려서 처리하는 형태)

생 NodeJs가 떠서 처리하기에는 아직 부족한 점이 많았다.

  • USB나 Drive 정보에 GUID를 뽑아서 처리하는 케이스
  • LanCard의 Mac Address를 추출해서 처리하는 케이스
  • PDF 이미지를 base64로 변환하는 케이스 (image처리시 OS Native 자원을 사용하는 경우)

위와 같은 케이스에서 기능개발에 문제가 발생하였다. python Module로 처리하면 되지만 StandAlong App으로 개발되어 배포되기 때문에 모든 사용자의 PC의 python을 설치하여 전처리기로 사용할수는 없는 노릇이다...

Backend Server가 있어서 중앙에서 처리할 수 있는 구조만 된다면 문제가 어느정도 해소되지 않을까 싶다.



역경을 딛고 배포성공..!

많은 역경이 있었지만 결국에 1년간의 개발 끝에 성공리에 배포 하였다.
배포는 Spring WebServer를 이용하여 다운로드 기능을 통해서 배포하였고 빌드는 Electron-builder를 통해서 빌드 하였다. WPF의 경우 툴에서 Release해버리면 그만이지만, Electron은 빌드전용 라이브러리를 받아서 빌드 명령을 내리면 5분정도 소요되고 빌드가 되었다.

WEB 환경임에도 오히려 신속하지 못한 Build 환경...



WPF vs Electron

개발하면서 느낀 WPF, Electron의 장단점을 적어보았다.

WPF

  • 장점
    • OS 자원을 직접 사용해서 퍼포먼스가 좋음.
    • Desktop 친화적인 프레임워크이다. Desktop App만을 위한 Library다수 존재함.
    • 랜더링 퍼포먼스가 압도적.
    • 저용량.
    • 배포 과정이 단순하다.
  • 단점
    • 높은 러닝커브
    • Xaml자체가 단점.
    • 커뮤니티가 잘 안되어있음.

Electron

  • 장점
    • 낮은 러닝 커브.
    • NodeJs의 방대한 라이브러리를 사용 할 수 있다.
    • 높은 생산속도.
    • Web Browser 환경, Desktop 환경을 동일하게 개발 가능.
    • Cross Platform 지원.
  • 단점
    • 크로미움을 내장하고 있어서 빌드시 기본 용량이 큰편.
    • 크로미움을 이용해서 Desktop App처럼 보이게 한것이다. 심도있는 Desktop이 되긴 어렵다.. 외부통신이 필요해보임.
    • 랜더링 성능이 WPF 비해 다소 떨어짐.
    • OS 자원을 이용하는 Native Code에서 부족한 편.
    • 빌드가 복잡하다. (Electron-Builder, Electron-forge 와 같은 NPM 라이브러리를 이용해서 빌드 해야한다.)


후기

Backend Server가 외부에 있고 기존에 웹개발자라면 Electron을 고려 해볼만 하다고 생각한다. 또 이미 서비스 중인 웹사이트가 있다면 주저하지 않고 도입해도 될 것 이라 생각된다.

다만, desktop app이 StandAlone 환경에서 서비스 되야한다면 Electron보다 WPF를 추천한다.

Electron 플젝을 헀지만 Electron을 만질 일은 거의 없었다. NodeJs, React, Typescript를 깊이있게 해볼 수 있어서 좋았다.

혹시 Electron 도입을 고민하는 개발자라면 Vue-Electron를 이용해여 Vue와 Electron의 구조를 한번에 잡아주는 보일러 플레이트가 있으니 고려해봄직 하다.

profile
hooeee
바구

0개의 댓글