회사생활 => 프리랜서 => 법인개설 테크를 타다가 더 나이를 먹기전에 저만의 서비스를 만들고 싶어서
일을 쉬며 육아와 개발에 몰두하고 있는 개발자입니다.
자바 스프링 + 프런트엔드 개발자로 오래 일했다보니 한동안 개인적으로 부족했던
쿠버네티스, 도커와 같은 인프라 영역에 집중을 하고 있었습니다.
1인 개발이다보니 모든걸 자동화 하는 과정에 집중하고 있었는데요.
어느정도 체계가 잡히고나서 다시 프런트엔드 관련으로 현업에서 애용하던 타입스크립트 + 앵귤러 조합으로
웹부터 모바일까지 하이브리드로 진행하려다가 우연찮게 플러터를 다시 보게 되었습니다.
플러터 초창기에 Dart에서 한번 어우.. 하고 후기들도 실사용엔 못쓰겠어요가 태반이라 잊고 살았었는데
2.0 이후로 정말 장족의 발전을 하였더군요!
1인 개발이니 기기별로 다른 언어로 개발하는건 부담이 커서 성능을 희생하고 하이브리드앱으로 고려하고 있었는데
성능도 리액트 네이티브도 쌈싸먹고 웹에 데스크탑까지 지원하는걸 보고 바로 강좌들을 탐독을 해보니
과장좀 보태서 아.. 프런트엔드 미래는 이거구나 싶은 감탄을 하고 있습니다.
구글의 특성상 또 토사구팽 당할지도 모르지만 현재로서는 지원만 계속해준다면 향후 현업에서 일을 할때도
주력으로 써보고 싶은 마음입니다.
저는 1년까지는 아니지만 6개월정도 삽질하다가 그냥 웹으로 하는게 생산성이 더 높겠다 싶어서 때려쳤네요.
주 원인으로는 어플리케이션 데이터 관리 구조의 복잡함(심지어 표준 모델이 없음), 마크업이 아닌 코드로 gui 표현이 난해함(한눈에 안들어옴, 리팩토링 힘듬), 관련 라이브러리 부족 (요즘엔 나아졌을듯), 앱 배포/심사 스트레스 등..
- 현재까지 플러터로만 스토어에 5개 이상 올린 입장에서 말씀 드리겠습니다.
- 상태 관리 => getx, provider로 거의 통일되고 있습니다.
- 마크업에 비해 생산성이 훨~씬 높습니다. depth가 깊어지면 적당히 메서드나 위젯으로 분리하면 됩니다.
- 이제까지 쓰고싶은데 찾지 못한 라이브러리는 없었습니다. ios나 android보다 라이브러리 사용에 있어서 훨씬 적극적으로 가능합니다.
- 앱 배포/심사는 기존 네이티브와 동일합니다.
- 플러터 웹은 제가 써보지 않아서 모르겠지만, 쓸수 있다 정도로 생각하는 입장이고 앞으로도 큰 기대는 안합니다.
마크업이 아닌 코드로 gui 표현이 난해함...
이부분은... 그냥 본인이 선언형 UI에 익숙해지지 못하셔서 ... 일뿐일 것 같네요.
웹에서 많이 사용하는 react.js의 컴포넌트를 렌더링하는 jsx도 유사한 구조입니다.
심지어 안드로이드도 요즘 jetpack compose 로 가고 있는데.. 그것도 선언형 UI 입니다.
위에 분이 말씀하신것처럼 선언형 UI는 depth가 깊어질거 같으면 component 화 하는 형태로 가면 됩니다.
1. dart 는 언어가 좀 old한 자바 스타일이라 변수가 요즘 웹개발에서 흔한 컨셉인 reactive 성격이 없어서 이벤트/변경 시에 프로그래머가 매뉴얼하게 일일히 쳐주고 연결해야 하는 경우가 많았음
2. markup 언에서 블럭 복사시 indent 가 왠만하면 쉽게 정렬이 가능한데, intellij ide가 바보인지 widget depth 이동하며 멤버들 수작업으로 indent 맞춰줘야 하는 경우가 너무 빈번..
3. depth 깊다고 component화 할때 widget boilerplate 코드가 많고 상위 변수 공유가 쉽게 안되서 react 등에서 하는것과 비교할 수가 없네요..
1. reactive 성격이 없다는건 오해가 있으신듯.. stream을 사용하면 이벤트/변경시에 UI변경 됩니다.
2. indent는... 언어 문제랑 전혀 무관하죠. IDE의 문제일 뿐 flutter / dart의 문제는 아닌거 같습니다.
3. 저도 react.js 써본 입장에서 ... bloc 패턴 + Provider 이나 위에분이 말씀하신 getx 써보시면 react에서 component 만드는거랑 크게 차이 나지 않는다고 생각합니다.
개발자가 들여야 하는 시간 total cost 관점에서 바라본겁니다. flutter 내재적인 문제가 아니어도 ide가 잘 안되면 개발자는 똑같이 빡치기 마련인거고, 그런거 다 포함해서 native 언어 개발보다 조금 나으면서 웹개발 기술로 페이지 찍어내는 속도에는 훨씬 못미치는 정도의 생산성으로 평가해봅니다. 플루터 까는게 아니라 웹같은 화면이 목표면 플루터 안쓰는게 좋겠다가 제 생각입니다. (그런거 많이 없죠)
몇개 단어로 퉁친다라고 보기에는...
개발자가 들여야 하는 total cost 관점... 으로 보면 말씀하신 react.js에 redux 붙이고 어쩌고하고 프로젝트 구성하고 스터디하고 익숙해 지는 시간이랑 비교하면 flutter로 stream, bloc나 getX 적용해서 앱 만드는거랑 크게 더 어렵거나 오래 걸릴건 없을거 같습니다.
그리고 flutter를 배워서 만들고자 하는 앱이 웹개발 기술로 찍어내는 정도의 앱보단 native로 만든 앱에 훨씬 가까울거 같습니다만....
그리고 flutter 까는거 맞으신거 같아요.
그리고 개인적으론 flutter 까셔도 상관없어요. 단점은 까여야죠. 저도 flutter 빠는 아니거든요.
댓글 달았던 관점은 flutter를 까셔서 반론 하려고 달았다기 보다는..
뭔가 기준이 내가 익숙한 도구들 대비 ~~가 별로 다 정도의 관점으로 이야기를 하시는데 그런 부분들이 react / flutter 양쪽 다 해본 입장에서 납득이 되지 않아서 였습니다.
넵. 저도 양쪽다 해본 입장에서 flutter나 react나 진입장벽은 비슷하다고 느꼈습니다만...
님이 flutter가 훨씬 "난해"하다고 빡칠일이 많다고 주장하시는걸 저도 굳이 반대는 않겠습니다.
네이티브 대비 성능이 필요한 부분은 ffi를 통해 충분히 갈음 할 수 있어서, 유용하게 잘 쓰는 중 입니다.
웹에 대비해서는... (핸디캡 사용자를 위한) 접근성 지원이나 3D 접목이 어려운 부분이 있긴 한데, 통일 된 개발 환경 (+크로스 플랫폼)이란 장점이 여타 단점을 상쇄하고 남음이라... 플러터의 손을 들어주고 싶습니다 ㅎㅎ
뭔가 이상하게 다트문법이 맘에 안들어서 시작이 어렵네요ㅜ
그래도 다시 도전해봅니다!
(플러터에 리액트 훅 같은건 없나요?)
회사 다니면서 짬짬히 했는데.. 생산성은 정말 좋은것 같아요.