15장 마치며

15.1 리액트 프로젝트를 시작할 때 고려해야 할 사항

15.1.1 유지보수 중인 서비스라면 리액트 버전을 최소 16.8.6에서 최대 17.0.2로 올려두자

• 리액트 16.8 이후로 훅이 소개되면서 함수 컴포넌트의 개념이 정립되어 중요한 업데이트가 이뤄졌다.
• 리액트 17 버전은 새루온 기능 출시 및 호환성이 깨지는 변경 사항을 최소한으로 맞춘 업데이트이므로 가능하다면 17버전으로 가는 것도 좋다.

클래스 컴포넌트를 함수 컴포넌트로 리팩토링 해야할까?

• 굳이 그럴 필요 없다
• 리액트 팀에서 클래스 컴포넌트를 제거할 계획이 없다고 했다.

15.1.2 인터넷 익스플로러 11지원을 목표한다면 각별히 더 주의를 기한다

IE11을 지원하는 애플리케이션은 각별히 라이브러리 설치에 주의해야 한다.

인터넷 익스플로러 11을 지원하지 않는 대표적인 라이브러리

• 리액트 : 18버전부터 IE11을 지원하지 않기로 했다
• Next.js : 13버전부터 공식적으로 IE11을 지원하지 않기로 했다
• query-string : 주소의 쿠리 문자열을 다루는 대표적인 라이브러리로, 6.x 버전부터 IE를 지원하지 않는다

15.1.3 서버 사이드 렌더링 애플리케이션을 우선적으로 고려한다

• 기본 HTML에 온전히 자바스크립트로 렌더링과 라우팅을 수행하는 싱글 페이지 애플리케이션은 대부분의 경우 라이트하우스와 WebPageTest, 구글 개발자 도구에서 좋은 결과를 얻기 어렵다.
• 많은 사용자를 감당해야 된다면 서버 사이드 렌더링을 고려하는 것이 좋다.
• 싱글 페이지 애플리케이션을 추천하는 경우
  • 제한적인 사용자에게 빠르게 웹페이지를 제공해야 하는 경우
  • 콘텐츠와 인터렉션이 매우 제한적인 소규모 웹페이지를 만드는 경우
  • 서버를 준비해야 할 상황이 여의치 않은 경우

15.1.4 상태 관리 라이브러리는 꼭 필요한 때만 사용한다

• 과거에는 리액트에서 리덕스를 무조건 설치해서 사용했었다
• 하지만 현재는 리액트 Context API와 훅의 등장으로 prop drilling 문제를 겪지 않고도 하위 컴포넌트에 원하는 상태값을 전달할 수 있게 됐다
• 문서 편집기 같이 관리해야 할 상태가 많고, 여러 상태를 합성해서 또 새로운 상태를 파생하는 등 상태에 대한 여러 가지 필요성이 많은 애플리케이션이라면 상태 관리를 사용하는 것이 좋다
• 비교적 정적인 애플리케이션에서는 상태 관리 라이브러리가 굳이 필요하지 않다

15.1.5 리액트 의존성 라이브러리 설치를 조심한다

• 리액트에 의존적인 라이브러리는 대부분 react-** 같은 이름을 가지고 있으며, 아래와 같은 의존성을 가지고 있다

{
    "peerDependencies": {
        "react": "^16.8.6 || ^17.0.0",
        "react-dom": "^16.8.6 || ^17.0.0"
    }
}

• 이때 반드시 이 peerDenpendencies가 설치하고자 하는 프로젝트의 리액트 버전과 맞는지 확인해야 한다
• 이 버전이 맞지 않다면 정상적인 방법으로 설치가 불가능하고, 설령 억지로 설치한다 하더라도 향후 문제를 일으킬 가능성이 크다
• 특히 리액트 18에서는 외부 상태를 관리하는 방법이 변경됐기 때문에 잘못 설치했다면 버그를 야기할 가능성이 크다

15.2 언젠가 사라질 수도 있는 리액트

15.2.1 리액트는 그래서 정말 완벽한 라이브러리인가?

• 리액트는 가장 널리 쓰이는 프론트엔드 라이브러리는 맞지만 여전히 리액트를 반대하는 사람들은 많다.
• 리액트를 반대하는 사람들의 의견을 아래와 같다

클래스 컴포넌트에서 함수 컴포넌트로 넘어오면서 느껴지는 혼란

• 리액트 공식 홈페이지에는 클래스 컴포넌트에 대한 설명도 작성되어 있어서 입문자를 혼란스럽게 한다
• 이에 반해 Svelte와 Vue는 문서가 깔끔하고 잘 정리돼 있는 편이다. 무엇보다 함수 컴포넌트와 클래스 컴포넌트와 같은 큰 패러다임의 차이도 없기 때문에 초보자가 훨씬 이해하기 편하다

너무 방대한 자유가 주는 혼란

• 리액트에서 스타일을 입힐 수 있는 방법은 다양하다
  • 외부 스타일시트 임포트
  • 인라인 스타일
  • CSS Module 기법 적용
  • styled-components
  • emotion
• 상태 관리 또한 다양한 옵션이 있다
  • Redux
  • MobX
  • Jotai
  • Zustand
  • React Tracked
  • Valtio
• 자칫 파편화된 리액트 기술 스택은 새로운 리액트 개발자에게 장애물이 될 수 있다

15.2.2 오픈소스 생태계의 명과 암

페이스북 라이선스 이슈

• 리액트는 BSD+Parents 라이선스를 사용하고 있었다.
• 이 라이선스는 '이 라이선스를 적용한 소프트웨어에 대해서 특정한 사건이 발생한다면 라이선스가 통지 없이 종료될 수 있다'라는 조항이 있다
• 2017년 7월, 아파치 재단에서 BSD+Parents 라이선스를 사용하는 것을 금지한다고 밝히면서 격론이 일어났고 결국 MIT 라이선스로 변경되었다
• 이 라이선스 사건은 한바탕 소동으로 끝났지만 개발자들에게는 자신이 오픈소스로 만든 소프트웨어에 대한 권리를 한순가에 잃어버릴 수 있다는 경각심을 갖게 하는 계기가 됐다

오픈소스는 무료로 계속 제공될 수 있는가? color.js, faker.js, 그리고 바벨

• 오픈소스인 바벨은 풀타임 개발자들을 고용해 급여를 주고 있지만 재정난이 있어 모금을 계속하고 있다고 밝혔다
• color.js는 고의로 무한 루프를 삽입한 코드를 커밋해 1.4.1을 배포해 버렸다
• faker.js은 5.5.3 버전에서 갑자기 6.6.6으로 넘어갔는데, 이 6.6.6 버전에는 아무런 코드가 남아있지 않았다.
• 우리는 npm 오픈소스 생태계 덕분에 700여 개의 라이브러리를 모두 무료로 사용하고 있지만 위와 같은 사례가 발생할 수 있다

15.2.3 제이쿼리, Angular JS, 리액트, 그리고 다음은 무엇인가?

• 과거에는 서버와 웹페이지가 함께 있는 프레임워크가 주를 이뤘다면 현재로 오면서 점차 프론트엔드 단독 프레임워크가 증가하는 것을 볼 수 있다
• 계속해서 새로운 프레임워크가 등장하고 있지만 그중에서도 리액트는 꾸준히 사랑받고 있다.
• 하지만 상태 관리 라이브러리를 중심으로 한 다양한 옵션에 대한 피로감, 훅에 대한 거부감과 어려움 등으로 인해 점차 부정적인 의견이 조금씩 나타나고 있다

15.2.4 웹 개발자로서 가져야 할 유연한 자세

• 어떤 프레임워크가 라이브러리를 사용하든 변하지 않은 사실은 HTML과 CSS, 자바스크립트가 웹 페이지를 구성하는 기초 기술이라는 사실이다
• 하지만 이 생태계가 계속 이 수준에서 머물러 있을 것이라는 뜻은 아니다. 최근에는 느린 자바스크립트를 대신할 하나의 방안으로 웹어셈블리가 떠오르고 있다
• 웹어셈블리는 C, C++, 러스트와 같은 시스템 프로그래밍 언어로 작성된 프로그램을 웹에서 사용할 수 있게 해준다
• 자바 스크립트보다 훨씬 더 빠른 언어로 작성돼 있기 때문에 일반적으로 웹에서 자바스크립트 기반으로 처리하기 어려운 작업을 웹어셈블리를 활용해 처리할 수 있다
• 하지만 웹 어셈블리는 자바스크립트에 대체하는 것이 아닌 함께 상호 보완적으로 실행되는 도구라고 보는 것이 적절하다
• 이 밖에도 Next.js에서 살펴본 SWC, 터보팩 모두 러스트로 작성되어 자바스크립트로 실행되는 바벨과 웹팩을 속도 측면에서 개선하려는 시도도 이뤄지고 있다
• 그렇다고 당장 리액트를 버리고 다른 프레임워크나 라이브러리를 배워야 하는 것은 아니다
• 중요한 것은 웹 개발이 HTML, CSS, 자바스크립트라는 토대 위에 세워졌음을 깨닫고 자바스크립트에 대해 깊게 공부하는 것을 추천한다
• 또한 11억 개가 넘는 웹사이트가 존재하는 인터넷에는, 리액트가 아닌 것들이 많다. 그렇기 때문에 리액트를 넘어 다양한 자바스크립트를 세계를 맛본다면 더욱 유연한 개발자가 될 수 있다