<aside> ✏️
목차
</aside>
React| 장점 | 단점 | |
|---|---|---|
| React | • 컴포넌트 기반 UI 설계로 재사용성 높음 | |
| • 다른 라이브러리와의 높은 호환성 | ||
| • csr방식이다 보니 동적인 페이지 개발 가능 | ||
| • 초기 설정이 간단함 | ||
| • 커뮤니티가 잘 형성되어 있음. (거대한 커뮤니티) | ||
| • Virtual DOM을 사용해 UI 변경 시 실제 DOM 대신 가상 DOM에서 먼저 렌더링을 처리함 | ||
| → 이를 통해 실제 DOM 조작을 최소화하여 성능을 향상시킴 | • IE8 이하 버전은 지원하지 않음 | |
| • 데이터 모델링, 라우팅, ajax 등 기능 지원이 안됨 | ||
| • Javascript, JSX 배경지식이 필수 | ||
| • 프론트엔드 단점과 같은 트렌드가 너무 빨리 변함 | ||
| • 상태 관리가 복잡함 | ||
| • 높은 유연성 → 커뮤니케이션 비용 | ||
| Vue | • 낮은 러닝커브 (바닐라 자바스크립트와 유사) | |
| • React 보다 빠름 (미세한 차이) | • 상대적으로 작은 커뮤니티 | |
| Angular | • 타입스크립트 기본 지원 | • 높은 러닝커브 |
| • 설정과 빌드 시간이 비교적 길음 | ||
| Next.js | • ssr 방식 → seo 친화적 | |
| • pre-rendering 방식으로 인해 웹페이지 미리보기 가능 | ||
| • 풀스택 개발 지원 | • react에 비해선 초기 설정이 무겁고 번들 사이즈가 큼. | |
| • React에 Vite만 사용했을 때와 비교 했을 때의 오버헤드 / 안정성 / 유지보수성에 단점 및 러닝 커브 이슈 존재 |
Typescript| 장점 | 단점 | |
|---|---|---|
| TypeScript | • 정적 타입 검사로 타입 안정성을 제공함. | |
| • 컴파일 과정에서 오류를 찾아, 개발 단계에서의 안정성을 높임. | ||
| • 유지 보수 및 협업에 유리함. | ||
| • 기존 자바스크립트와 완벽하게 호환됨. | ||
| • 기존 자바스크립트 프로젝트에 타입스크립트를 점진적으로 적용해서 마이그레이션할 수 있음. | ||
| ◦ 타입을 미리 체크하기에 JS에 비해 실행 시간이 빠름. | ||
| ◦ 타입스크립트는 class에서 private 기능 지원, interface, type 등을 통해 더 쉽게 객체 지향 프로그래밍을 할 수 있음. | • 컴파일 시간이 생겨 빌드 시간이 증가함. | |
| • 러닝커브가 있다. interface, type, enum 등 자바스크립트에서는 없는 기능을 추가로 배워야 함. | ||
| ◦ type에 익숙치 않아 any를 남발할 경우 타입스크립트의 장점을 활용할 수 없음. | ||
| • 초기 설정이 복잡함. | ||
| ◦ 기존 자바스크립트 코드에 타입을 선언하고 지정하는 과정에서 코드의 수가 증가함. | ||
| JavaScript | ◦ 브라우저에서 즉시 실행 가능 | ◦ 타입 안전성 부족 |
Vite| 장점 | 단점 | |
|---|---|---|
| Vite | • 모든 모듈을 하나의 컨텍스트 기반으로 실행시키기 때문에 별도의 평가 과정이 필요하지 않아 빠른 실행을 보장함 | |
| • 설정이 매우 간편함 | ||
| • ESM을 사용해서 최신 브라우저에 적합함 | ||
| • EsBuild를 통해 번들링을 하기 때문에 빠른 속도의 번들링을 제공 | ||
| • dynamic import를 지원하지 않고 모듈 간의 순환 참조 문제가 발생할 경우, 이를 제어하지 못함 | ||
| • webpack에 비해 플러그인이 적음 | ||
| • 구형 브라우저 지원에 제약이 있음 | ||
| • Next.js와 직접적으로 호환되지 않음 | ||
| Webpack | • 각 모듈을 함수로 감싸 스코프를 격리시키기 때문에, 모듈 간의 식별자 충돌을 완벽하게 방지할 수 있음 | |
| • Module Cache를 통해 순환 참조 문제가 발생한 경우, 캐싱된 모듈을 반환하기 때문에 제어가 가능함 | ||
| • 역사가 길어서 vite에 비해 더 많은 로더와 플러그인을 지원함 | • 각 모듈이 런타임 과정에서 실행되고 Module Cache에 추가되기 때문에, 실행 속도가 느림 | |
| • 유연하지만 초기 설정이 복잡함 |
tailwindcss| 장점 | 단점 | |
|---|---|---|
| Tailwind CSS | • 클래스 작명 불필요 | |
| • 개발 속도 빠름 | ||
| • 런타임이 아니라 빌드타임에 스타일을 적용하고, 불필요한 css는 제거해서 초기 로딩 속도가 빠름 | • 가독성이 좋지 않음 | |
| • 동적 스타일 적용에 대한 유연성이 떨어짐 | ||
| Styled-Components | • 컴포넌트 기반 스타일링으로 재사용성 높음 | |
| • 동적 스타일링 용이 | ||
| • 스코프가 지역적이어서 스타일 충돌을 방지 | • 런타임에 스타일을 생성하므로 초기 로딩 속도가 Tailwind CSS에 비해 느릴 수 있음 |
Zustand + Tanstack-Query| 장점 | 단점 | |
|---|---|---|
| Zustand | • 작은 번들사이즈 | |
| • 낮은 러닝커브 | ||
| • 간단한 설정 | ||
| • 선택적 리렌더링 지원 | ||
| • typescript 지원 | ||
| • 보일러 플레이트가 거의 없음 | • 서버 상태 관리에 한계 | |
| • 작은 커뮤니티 | ||
| • Redux에 비해 미들웨어 지원 부족 | ||
| • 공식 디버깅 도구를 지원하지 않음 | ||
| (상태 변화 추적하기 비교적 어려움) | ||
| • 상태관리 복잡해지면 힘듦 | ||
| (트리기반으로 관리하지 않음) | ||
| Tanstack Query | • 비동기 데이터 관리에 특화 | |
| • 서버 상태 자동 캐싱 및 최신성 자동 유지 | ||
| • 서버와의 손쉬운 동기화 및 재검증 지원 | ||
| 편리한 사용법 | • 고급 기능 학습 필요 | |
| • 클라이언트 상태 관리에 비효율적 | ||
| (다른 쿼리키 사용시 데이터 일관성 꺠짐) | ||
| • 데이터 캐싱 전략 복잡 | ||
| • 새로고침시 상태 초기화 (캐싱 메모리 기반) | ||
| • 러닝커브 존재 | ||
| Redux | • 거대한 커뮤니티 | |
| • DevTools 지원 | • 보일러플레이트가 많음 | |
| • 러닝커브 높은 편 | ||
| Context API | • 기본 제공으로 추가 라이브러리 불필요 | |
| • 간단한 상태 관리에 적합 | • 성능 최적화 어려움 |
zustand를 선택Tanstack-Query를 선택Express| 장점 | 단점 | |
|---|---|---|
| Express | • 빠르게 API 서버 구축 및 확장 가능 (간단하고 가벼운 설정) | |
| • 간편한 설정과 높은 자유도로 미들웨어와 라우팅 쉽게 관리 용이 | ||
| • 경량 서버라 node.js와 잘 결합되어 응답이 빠른 편 | • 자유도가 높은 만큼 초기 세팅과 컨벤션 맞추기가 어려운 편 | |
| • 타입스크립트 지원하지 않음 (별도 세팅 필요) | ||
| • 대규모 프로젝트에서는 관리가 어렵고 추가 설정이 필요함 | ||
| • 웹 소켓을 지원하지 않음 → 실시간 데이터 처리가 필요한 경우 Socket.IO와 같은 별도의 라이브러리를 도입해야됨 | ||
| Nest.js | • 타입스크립트가 기본적이다보니 초기설정의 부담감이 적음 | |
| • RESTful api 서비스 관련 주요 기능 기본적으로 제공 (HTTP 연결, DB 연동, 미들웨어 구축, 인증 보안 등) | ||
| • 필요한 클래스를 일괄적으로 자동생성해주는 명령어 제공 | ||
| • 스웨거 문서를 자동 연결 | • 백엔드에 익숙치 않다면 러닝커브 존재 | |
| • 간단한 서버 성능 고려시 비효율적 (다양한 기본 설정들이 존재하기 때문에 프레임워크가 무거움) | ||
| • 자유도 낮은 편 |