-
Notifications
You must be signed in to change notification settings - Fork 2
기술스택
박정현 edited this page Apr 18, 2024
·
4 revisions
팀원들 모두에게 익숙하여 빠른 시간 안에 기능을 구현할 수 있는 웹 프론트엔드 프레임워크인 React를 선택했다. 또한 서비스 특성상 페이지 수가 많지 않고, SEO를 고려하지 않아도 되어 순수 React만으로도 충분하다고 판단했다.
최신 트렌드인 CSS-in-JS 스타일링 방식을 프로젝트에 적용해보고 싶었고, 가장 대표적인 styled-components를 선택했다.
리스트 순서가 변경되거나 컴포넌트 마운트/언마운트시에 애니메이션 적용이 필요했고, React에서 이를 쉽게 다룰 수 있는 React전용 애니메이션 라이브러리인 Framer-motion을 선택했다.
상태를 관리하기 위한 코드가 매우 적어 사용법이 간단하고 유지보수하기 쉬우며 redux-toolkit을 통한 디버깅 또한 가능하다는 장점이 있어 선택했다.
라이브러리 내부적으로 접속한 클라이언트를 Room으로 나누어 주는 기능이 있어 구현이 편리하고, 실시간성을 구현하는 방법 중 러닝커브가 제일 높아 선택했다.
당시 팀원들 모두 Node.js 기반의 백엔드 개발만 가능했고, Express와 NestJS중 아키텍처가 통일되어 있어 협업에 유리하고 모듈 단위의 개발이 가능 NestJS를 선택했다.
Go 언어로 작성된 esbuild를 사용하여 Webpack과 같은 기존 번들러 대비 10~100배 속도가 빠른 번들러를 경험해보고 싶었다.
styled-components
- 고려대상
-
Emotion
- 장점: 번들 사이즈, 속도 측면에서 (전반적으로)
styled-components
보다 퍼포먼스가 좋다. - 단점: inline 스타일 -> 가독성이 떨어진다.
- 장점: 번들 사이즈, 속도 측면에서 (전반적으로)
-
styled-components
- 장점: 팀 구성원들에게 더 익숙하다.
- 단점:
Emotion
에 비해 성능 퍼포먼스가 낮다.
tailwind
-
- 선정 근거:
- 성능을 고려했을 때
Emotion
>styled-components
이지만, 근소한 차이이며 버전에 따라styled-components
의 속도가 더 빠를때도 있다. - 즉, 성능상 유의미한 차이가 없다고 판단하여, 팀원들에게 더 익숙한
styled-components
를 선택하였다.
- 성능을 고려했을 때