플러터를 찬양하는 사람들이 많은 것 같고 단점도 알아야할텐데 라는 생각으로 적어본 글입니다.
- 코드푸쉬
제 생각에는 가장 큰 비교점입니다.
코드푸쉬가 없는 플러터는 절대로 리액트네이티브를 넘어설 수 없습니다.
플러터나 리액트네이티브는 스타트업에서 많이 사용합니다.
그들은 빠른 개발과 대응이 필요하고 플러터는 이를 만족시킬 수 없습니다.
코드푸쉬로 에러 대응이나 신기술 개발을 즉각적으로 도입할 수 있는 리액트네이티브를 선택해야합니다.
테슬라/인스타그램/쇼피파이/토스글러벌/리디북스 등 많은 기업들이 코드푸쉬라는 기능때문에 swift와 kotlin을 선택하지않고 리액트네이티브를 선택합니다.
네이티브(swift, kotlin)로 개발하던 회사들이 플러터를 선택해야하는 이유는 뭘까요? 제가 볼 땐 없습니다.
- 다트라는 언어의 단점
두번째, 개인적으로 처음 개발을 시작하는 사람에게 다트 언어를 추천하는 사람은 걸러야한다고 생각합니다.
다트언어로 먹고 살 수 없습니다. 개발자 시장에서 다트언어는 지옥입니다.
리액트네이티브는 현재 가장 많이 쓰고 추천하는 언어인 javascript를 사용하고 있습니다.
리액트네이티브가 망해도 javascript를 사용하기 때문에 언제든지 reactJS나 웹개발로 넘어갈 수 있습니다.
다트가 초반에 나왔을 때 단점이 시간을 기록하는 방법에 대한 기능이 부족하다와 다국어지원이 미약하다가 큰 단점이였습니다.
현재는 극복이 어느정도 된것 같지만 아직도 부족한 점이 많습니다.
- 에어비앤비가 리액트네이티브를 버린 점
3번째, 에어비앤비는 2017년 리액트네이티브를 버렸습니다. 이견이 없습니다. 다만 오래된 이야기입니다.
현재는 에어비앤비 대신 쇼피파이와 트위터가 대신하고 있습니다.
둘은 이견없는 빅테크 기업이고 현재 쇼피파이의 리액트네이티브 라이브러리 지원과 트위터의 웹사이트는 리액트네이티브 웹으로 만들어졌습니다.
- 플러터의 부족한 하위호환성
4번째, 개인적으로 플러터1.0부터 관심있게 봐왔지만 플러터2.0으로 넘어갈때 1.0을 아예 지원안하는 걸 보고 플러터에 대한 관심을 많이 접었습니다.
리액트네이티브와는 다르게 개발자들을 무시하는 행위였다고 생각합니다.
리액트네이티브는 현재 hook 이라는 펑셔널컴포넌트를 디폴트로 사용합니다.
하지만 기존에 쓰던 클래스 컴포넌트를 계속 지원하고 있습니다.
그리고 버전업을 할때 큰 무리없이 업그레이드가 되는 편입니다.
- 성능에 대한 오해
5 흔히들 리액트네이티브는 성능이 너무 느리다. 라고 말합니다. 이전에는 말이죠.
근데 지금은 다릅니다. 리액트네이티브의 Hermes 엔진에 대해서 설명하는 유투버를 한명도 본적이 없습니다.
리액트네이티브가 느린 이유는 JSI 라는 브릿지 모듈 때문이고 해당 브릿지의 아키텍쳐는 hermes 엔진의 변화로 플러터와 견줄만한 성능의 발전이 있었습니다.
- 로티 미지원
최근에 앱개발은 인터렉티브한 개발이 필요해졌습니다.
예를들면 토스에서 버튼 누를때 나오는 간단한 애니메이션들은 로티로 만들어졌습니다.
그리고 이런 기능들을 사람들은 원합니다.
이런 간단한 애니메이션들을 로티가 지원하는데 플러터는 공식적으로 로티에서 지원하지 않습니다. 리액트네이티브는 지원하고 있습니다.
- Stripe 미지원
우리나라는 스트라이프가 들어오지 않았지만 해외에서는 스트라이프를 쓰지 않는 기업들을 찾아보기 힘듭니다.
공식적으로 스트라이프는 플러터를 지원하고 있지 않습니다.
로티와 같이 커뮤니티 라이브러리가 존재하죠. 즉 언제든지 지원이 끊길수 있다는 단점이 존재합니다.
요약
플러터는 코드푸쉬/다트언어/하위호환성 등 의 이유로 리액트네이티브에 비해 별로다.
반박시, 여러분의 의견이 맞습니다.
저도 아직은 플러터에 비해 RN 이 더 장점이 많다고 생각합니당 :)
구글에서의 플러터의 존재감은 단순히 플러터 하나만 바라보고 접근하지는 않는 것 같습니다.
퓨시아 프로젝트와 연관해서 차후 안드로이드에서 퓨시아로 os 변경시 앱 개발적인 부분에서
완충적 역활을 플러터에서 맡길려고 하는 모양새가 큽니다.
그래서 현재 퓨시아에서 응용프로그램 메인 개발 플랫폼을 플러터로 지정해두고 있고요.
다트는 원래 자바스크립트를 대체 하기 위해서 나왔는데 다트의 실패 이유는
언어 자체의 문제라기 보다는 구글의 문제였죠.
구글의 크롬이 엄청나게 약진을 한 상태에서 다트가 나왔을때
모질라, 마이크로 소프트, 애플에서 구글을 견제하기 위해서
의도적으로 자사 브라우저에서 다트를 배제하였습니다.
개인적으로 봤을때 개발환경 자체는 압도적으로 플러터가 좋았습니다. 처음 개발 환경 세팅할때 플러터쪽은 단순했거든요 flutter sdk만 ide에 연결해주면 그다음 부턴 무리없이 바로 개발이 가능 했습니다.
기타 안드이드 sdk 경로나 jdk 경로를 따로 지정해줄 필요 없이 android studio만 깔면 자동 인식되구요
rn쪽은 일일이 세팅해야될게 플러터에 비해 많았습니다.
거기다 개발환경 세팅 중 나오는 트러블 이슈 같은 경우도 flutter 보다는 rn이 훨씬 많았었네요.
ide에서 지원도 플러터쪽이 압도적으로 띄어난편 입니다.
vs code나 안스를 쓰지 않는 기준에서 flutter는 intellij를 쓰고 rn은 WebStorm을 쓰는데
개발자 도구 창이나 기타 툴등은 rn은 크롬 개발자 페이지를 별도로 열어서 처리를 하고 flutter는 ide내에서 전부 처리가 가능 하였습니다.
물론 rn도 기본적인 인텔리센스는 좋은 편입니다만.... 플러터 쪽이 간편한 부가적 리팩터링 기능이 많습니다.
예를 들어 자식뷰를 삭제 하거나, 뷰를 감싸주는 부모 뷰를 추가 할때
intellij에서는 한번의 리팩터 명령으로 처리해서 따로 손을 볼 필요가 없습니다.
(이런 이유로 플러터를 개발할때는 VS Code보다는 Android Studio나 Intellij를 더 추천합니다.
편한 기능이 너무 많아요....)
그리고 flutter에서는 기본적으로 터미널등을 전혀 안쓰고도 IDE안에 있는 기능으로만 개발이 가능 할 정도지만
rn은 필연적으로 커맨드 라인을 많이 사용하게 됩니다.
플러그인 관련 문제는
rn에서는 기본적인 스테이터스바 처리 및 네비게이터 처리 조차도 서드파티 플러그인을 깔아야 되는데..
리스크라고 치면 이쪽이 더....;;;;
하위호환성 이것도 flutter가 더 나아 보이더군요..
호환성 관련 이슈는 null safty 관련된 이슈가 있는데 이 부분은 랭귀지 버전이 아예 올라가서 혼돈의 장이었습니다.
그 외에는 마이그레이션은 안정적이었습니다.
또한 sdk와 프로젝트가 분리되어 있어서 롤백하는 것도 큰 문제는 아니였죠...
rn은 마이그레이션시 미리 형상관리나 별도 수단으로 백업을 하고 하죠....
마이그레이션 고통은... rn에서 더 심각했던걸로 기억합니다.
플러터보다 rn이 플러그인 의존성이 훨씬 높아서 버전이 올라가면 플러그인들이 버전 충돌하는게 플러터보다 심각하다고 들었습니다.
전반적인 짜임새 및 만듬새는 확실히 플러터쪽이 돈이 많이 들어간듯한 느낌을 보여 주고 있으며
rn은 오픈소스 재단에서 만들때 특유의 거친 느낌이 있습니다.
다만.....
이 모든 단점을 씹어먹어버리는게... 저는 코드 푸시라고 생각합니다.
다음 프로젝트를 개발 할때 쾌적함은 플러터가 훨씬 좋은데... 코드 푸시때문에 rn으로 마음이
기울고 있으니 ㅜㅜ
물론 플러터에도 코드 푸시 기능이 써드 파티 라이브러리로 존재는 하지만 상용 서비스로는 아직
믿음이 안갑니다.
그러나 코드 푸시 기능이 앞으로 지속 될 수 있을지는 의심을 해볼 수는 있겠네요...
구글 플레이를 만드는 주체는 구글이고 플러터를 만드는 주체 또한 구글입니다.
구글 플레이 정책 약관 수정의 권한 역시 구글이 가지고 있습니다.
리액트 네이티브의 코드 푸시 때문에 플러터의 점유율이 방해를 받고 있다면
욕 한바가지 먹을 각오를 하고 스토어 정책에서 코드 푸시기능이 있으면
심사 거부 및 업데이트 거부를 할 수 있겠죠..
(구글 인앱 사태때 보여준 구글의 패기는 대단했네요.... 이것이 플랫폼을 가지고 있는 회사의 패기입니다.)
비슷한 예로... 예전 애플의 iOS앱에서 구글, 페이스북 아이디로 로그인 기능은 많이 쓰고 기껏 만들어 놓은
애플 아이디 로그인은 많이 안쓰이니까.
타사 sns로그인 기능이 있으면 애플 아이디 로그인하기 기능 안집어 넣으면 심사 거부로 정책을 바꿔 버렸죠...
플러터와 안드로이드를 만드는 회사가 같은 회사라는 것의 희대의 변수 일 수도 있습니다.
그런데 네이티브로 개발하던 회사가 플러터를 선택할 이유는 있다고 생각됩니다. 다만 말씀하신대로 리액트네이티브와 플러터를 저울질해서 리액트네이티브를 선택할수는 있겠지만요.
일단 제 주력 언어가 C++과 같은 객체지향언어이다 보니 다트가 오히려 자바스크립트에 비해 진입장벽이 현저히 낮았습니다. 그리고 플러터가 지원해주는 기본 위젯도 많고 packaging 관리나 tool들도 쉽고 가볍게 쓰기 좋도록 잘 만들어졌다고 생각합니다.
그리고 1.0에서 2.0으로 넘어갈때도 하위 호환을 포기했다고 하기에는 migration tool도 지원해줬고 수동으로도 고치기 어렵지 않았던거 같습니다. 제가 진행하던 프로젝트들도 다 migration tool로 수작업 없이 2.0으로 넘어 갈 수 있었거든요.
말씀하신대로 코드 푸쉬가 워낙 강력해서 스타트업들은 RN을 사용하는게 더 나을 수 있겠지만, 자바와 같은 언어를 알고 있고 간단한 프론트엔드를 빨리 만들어야 하는 사람들에게는 저는 플러터를 추천합니다.
그래도 크로스 플랫폼 프레임워크를 선택하라고 하면 플러터를 고를 것 같네요.
RN 과 플러터를 고민하는 날이 왔을 때 참고할 수 있는 정보를 덕분에 알아갑니다.
세상엔 (특히 사람이 만든 경쟁 기술들 사이엔) 절대적인 건 없는 거니까요.
- 코드푸쉬
-> 제가 생각하는 유일한 rn의 장점입니다.
- 다트라는 언어의 단점
-> 다트언어가 js에 비해 부족한 점이 어떤게 있는지 모르겠네요. 자바, 코틀린에 익숙하신 분이라면
러닝커브가 아주 낮습니다. 하루 이틀 만져보시면 크게 이질감 없이 다루실 수 있습니다.
시간을 기록하는 방법, 다국어 지원 같은 경우에는 납득하기 힘들지만 dart language의 문제는 아닙니다.
- 에어비앤비가 리액트네이티브를 버린 점
-> 플러보다 비교 우위에 있다는 점과는 상관이 없는 것 같습니다.
- 플러터의 부족한 하위호환성
-> 하위 호환성을 버렸다기 보다는 Null safety가 추가된 겁니다. python2에서 python3로 넘어갔듯이 부족한 점을 끌어안고 가는 것 보다는 과감히 업그레이드하는게 나은 선택이라고 생각됩니다. 자바스크립트 같이 초기 언어의 문제를 계속 끌어안고 가는 것 보다는 낫습니다.
-> rn은 플러터에 비해 아주 소극적으로 업데이트 되고 있습니다. 장점이 되는지는 모르겠습니다.
- 성능에 대한 오해
-> hermes를 써본 적은 없지만, 네이티브 코드로 빌드되는 플러터보다 성능에서 우위에 있을거라고는 생각이 안드네요.
로티 미지원
-> https://pub.dev/packages/lottie
Stripe 미지원
-> https://pub.dev/packages/flutter_stripe
- 패키지들이 미지원이라는게 어떤 의미에서 사용하신 건지 모르겠지만 둘다 써본 경험으로는 플러터가 rn에 비해 외부 라이브러리 지원이 느리다거나 적지는 않습니다. 최근 서비스들은 rn보다 플러터를 더 우선하고 있다고 생각합니다.
지금이야 그냥 봐주지만, 나중에 보안상의 문제로 제재를 가하면 그것도 골치 아플 것 같습니다.
플러터 팀에서도 그 문제에 관해서 언급하고 있는 것을 보면,
분명히 스토어 정책과 보안에 관한 우려가 있을 거라 봅니다.
지금에서는 신박한 기능이지만, 보안상의 이유로 정책상 허용하지 않게 되지 않을까요.
언어기능(javascript) 중에서 지원하는 부분과 작업중인 부분 등을 나열해 놓은 내용이 있는대요,
이 목록들을 한번 보시고 '지금 도입해도 문제없는' 상태인지 확인해 주시면 감사하겠습니다.
(플러터 vs 리액트네이티브 논의와는 별개입니다)
https://hermesengine.dev/docs/language-features
유튜버 라면 상당히 자극적인 제목 잘 뽑으시는것 같아요. 흥할수 있겠어요.
왜 내가 선호하는거나 쓰는건 좋고 ... 그 라이벌(?) 기술은 까야 하는 걸까요?
세상에 만능 도구는 없는 법인데 말이죠.
나는 이거보다 저게 좋다... 는 인정인데.
나는 이거 좋으니 저건 별로다.... 라는건 좀 좋보이진 않네요.
"객체지향 관련되어서 dictionary로 구현하는 것 보고 좀 충격" 받으실 필요는 없으십니다. 스크립트 언어는 대게 그런식으로 구현됩니다.
백엔드를 swift 로 개발 하는게 있었긴 했는데 결국 묻혀버리는것 같습니다.
그래도 리액트/리액트 네이티브 개발할 때 (그 외 다른것들도) typescript 를 사용하면 타입스크립트 설정에 따라 다르지만 상당히 타입과 null 에 관해서 깐깐하게 굽니다. 정말 귀찮을 정도라서
여럿이 하는 프로젝트면 typescript 로도 괜찮은것 같습니다. (any 를 남발하지 않는다면...)
장점만 있는 프레임워크가 있을까요? 저희는 선택지가많다고 생각하고 프로젝트할때마다 어떤게 가장 유리할지 고민하고 적용하고 있어요
툴이 문제가 아닙니다.
둘다 동일하게 어플을 만들 수 있습니다.
둘다 비슷하게 최적화를 통해 속도를 개선 할 수 있습니다.
code push 가 좋긴 합니다만. 1년 정도 어플 만들어서 서비스 해보니 codepush 가 없다고 해서 딱히 아쉽지는 않았습니다.
저도 처음에 flutter 로 개발하고자 마음 먹었을때는 codepush 가 없어서 고민 이였는데. 막상 배포해서 서비스 해보니 그렇게 까지 아쉬운 기능은 아니였습니다.
구글 은 보통 3~4 시간 정도 걸리고요. 애플은 상황에 따라 다르지만 평균 12 시간 이내에 통과 되고 있습니다.
갤럭시 스토어가 좀 오래 걸리는데. 1~2 일 정도 소요 됩니다.
어느툴이 더 좋은지 보다는. 어떤 어플을 만들고 어떤 서비스를 제공 할지가 더 중요 합니다.