Skip to content

기술스택

박정현 edited this page Apr 18, 2024 · 4 revisions

React

팀원들 모두에게 익숙하여 빠른 시간 안에 기능을 구현할 수 있는 웹 프론트엔드 프레임워크인 React를 선택했다. 또한 서비스 특성상 페이지 수가 많지 않고, SEO를 고려하지 않아도 되어 순수 React만으로도 충분하다고 판단했다.

styled-components

최신 트렌드인 CSS-in-JS 스타일링 방식을 프로젝트에 적용해보고 싶었고, 가장 대표적인 styled-components를 선택했다.

Framer-motion

리스트 순서가 변경되거나 컴포넌트 마운트/언마운트시에 애니메이션 적용이 필요했고, React에서 이를 쉽게 다룰 수 있는 React전용 애니메이션 라이브러리인 Framer-motion을 선택했다.

Zustand

상태를 관리하기 위한 코드가 매우 적어 사용법이 간단하고 유지보수하기 쉬우며 redux-toolkit을 통한 디버깅 또한 가능하다는 장점이 있어 선택했다.

Socket.IO

라이브러리 내부적으로 접속한 클라이언트를 Room으로 나누어 주는 기능이 있어 구현이 편리하고, 실시간성을 구현하는 방법 중 러닝커브가 제일 높아 선택했다.

NestJS

당시 팀원들 모두 Node.js 기반의 백엔드 개발만 가능했고, Express와 NestJS중 아키텍처가 통일되어 있어 협업에 유리하고 모듈 단위의 개발이 가능 NestJS를 선택했다.

Vite

Go 언어로 작성된 esbuild를 사용하여 Webpack과 같은 기존 번들러 대비 10~100배 속도가 빠른 번들러를 경험해보고 싶었다.


styled-components

styled-components

  • 고려대상
    • Emotion
      • 장점: 번들 사이즈, 속도 측면에서 (전반적으로) styled-components 보다 퍼포먼스가 좋다.
      • 단점: inline 스타일 -> 가독성이 떨어진다.
    • styled-components
      • 장점: 팀 구성원들에게 더 익숙하다.
      • 단점: Emotion에 비해 성능 퍼포먼스가 낮다.
    • tailwind
  • 선정 근거:
    • 성능을 고려했을 때 Emotion > styled-components이지만, 근소한 차이이며 버전에 따라 styled-components의 속도가 더 빠를때도 있다.
    • 즉, 성능상 유의미한 차이가 없다고 판단하여, 팀원들에게 더 익숙한 styled-components를 선택하였다.
Clone this wiki locally