241229 기초 복습

📗 리액트를 왜 선호하는지 대표적인 이유

1. 명시적인 상태 변경: Angular의 양방향 바인딩과는 반대되는 단방향 바인딩 = 간단함, 유연함 제공

• 양방향 바인딩 단점:
  뷰의 변화가 컴포넌트에 영향을 미칠 수도, 반대로 컴포넌트릐 상태가 변경되면 뷰의 상태가 변할 수도 있음

  편리함을 제공하지만, 코드의 규모가 커질수록 변화가 무엇으로 인해 일어났는지 파악하기 어려워짐

• 양방향 바인딩 = 항상 나쁘다? X
  단방향 바인딩은 항상 변화를 감지하고 업데이트하는 코드를 매번 작성해야 함 = 코드의 규모가 증가하는 단점

  그렇지만, 단방향 바인딩은 양방향에 비해 데이터 흐름의 변화가 단순하기 때문에 코드를 읽기 쉽고 버그 야기 가능성이 비교적 적음
  

2. JSX(JavaScript XML)

• Angular는 뷰를 표현하기 위해 문자열 템플릿을 사용하고, Angular에서만 사용되는 전용 문법을 익혀야 하는 단점

• 리액트는 HTML에 자바스크립트 문법을 더한 JSX를 사용하는데, 기존에 알고 있는 JS에 HTML을 살짝 가미한 수준이기에 고유의 몇가지 특징만 이해한다면 손쉽게 JSX 코드 구현 가능

3. 비교적 쉽고 간결함

• 입문자도 리액트 기반 프로젝트를 할 수 있어서 선호되는 편
  but, 초기에는 쉽지만 이를 완벽히 이해하고 성능을 최적화하는 것은 상대적으로 어려운 축에 속함

4. 강력한 커뮤니티, 그리고 메타

• Angular와 다르게 단순 UI를 위한 라이브러리로만 작동함으로써 그 역할에 제한을 두고 그 외의 모든 것에 자유도를 두었음
  이는 개발자들이 리액트를 기반으로 다양한 것을 시도해 볼 수 있었고, 그로 인해 커다란 커뮤니티를 얻을 수 있게 됐음

• 오픈소스가 빠르고 안정적으로 성장할 수 있기 위해서는 중심이 되는 메인 스폰서의 역할이 중요한데, 리액트는 메타 (전 페이스북)을 등에 업었기에 꾸준히 성장했음

📗 React의 역사

• 2000년대 까지만 하더라도 이른바 LAMP 스택이라 하는 Linux, Apache 웹 서버, MySQL, PHP를 활용한 웹 개발이 주를 이루던 시기

• 대부분 데이터베이스에서 필요한 데이터를 불러온 후, 웹 서버에서 HTML 페이지를 만들어 클라이언트에 제공하는 방식으로 작동함

• 콘텐츠는 사용자나 기타 다른 환경에 따라 서버에서 동적으로 생성하고, 웹 브라우저는 이를 단순히 다운로드받아 렌더링하며, 자바스크립트는 폼 처리와 같은 부수적인 역할만하는 방식이었음

• 2010년 이후로 JQuery가 점차 비공식 표준으로 자리 잡기 시작했음
  2011년 공식적으로 표준으로 등록된 웹소켓, 캔버스, SVG, 지오로케이션 등 점차 다양한 기능을 브라우저에서 지원하기 시작했고, ES5가 처음으로 표준 스펙으로 자리 잡았음

• 브라우저 환경이 급변하기 시작함
  자바스크립트는 적극적으로 DOM(Document Object Model)을 수정해 다양한 인터랙션을 보여줬고, Ajax(Asynchronous JavaScript and XML)를 활용해 서버뿐만 아니라 클라이언트에서도 서버와 통신해서 데이터를 불러오기 시작함 = 코드가 점차 복잡해짐

• 이러한 필요성 때문에 등장한 것이 구글에서 만든 AngularJS, CoffeeScript, Underscore.js의 제작자 제레미 아쉬케나스가 선보인 Backbone.js
  각각 MVVM(Model-View-VideModel)과 MVC(Model-View-Controller) 패턴을 기반으로 나날이 복잡해지는 JS 코드를 체계화하고자 노력했음

• 페이스북은 자바스크립트 번들 사이즈를 최대한 줄이고 싶었지만 타임라인과 같은 실시간성을 강조하는 기능 및 다양한 요구사항으로 인해 자바스크립트에 의존하는 것을 피할 수 없었음

• 페이스북에게 있어 웹의 중요성을 더욱 부각시킨 사건이 있었으니 바로 스파르탄 프로젝트. 이 당시 애플의 강력한 앱 규제에 반발해 만들어진 프로젝트로, 페이스북 iOS 앱 대신 애플의 사파리(Webkit)에서 작동할 수 있는 페이스북을 만들기 위해 추진됐음

• 이 무렵 등장한 HTML5는 표준만 잘 지킨다면 PC, 모바일 환경에 상관없이 모두 동일한 서비스를 제공할 수 있는 가능성을 제시했음

• 그러나 모든 어플을 HTML5로 만들겠다는 스파르탄 프로젝트는 성공하지 못했음. 이후 18개월 동안 iOS용 페이스북 앱을 네이티브로 다시 개발하고, 안드로이드 앱도 출시하면서 공식적으로 스파르탄 프로젝트가 실패했음을 알렸음

• 네이티브로 만든 어플이 HTML5로 만든 것보다 훨씬 빠르고 안정정이었기 때문임. 이러한 프로젝트 실패가 웹 생태계에까지 부정적인 영향을 끼치진 않았음

• HTML5 기반 하이브리드 앱으로 개발하는 방식은 인터랙션이 복잡하지 않거나 성능이 크게 중요하지 않은 서비스에서 여전히 선호

📗 페이스북 팀의 대안으로 떠오른 리액트

• 리액트의 첫 프로젝트는 게시물 하단에 있는 댓글, 공유 버튼이 있는 화면인 UFI(Universal Feedback Interface)를 구현하는 것이었음

• 사람들은 좋아요를 누르고 댓글을 다는 행위 등이 모두 즉각적으로 이루어지길 바랬고, 이를 해결하기 위해 많은 의견이 모인 결과로
  지금 우리가 알고 있는 JSX 구문, Flux 패턴에 대한 아이디어 등장

• 당시 리액트에 대한 반응은 좋지 못했음
  HTML과 JS는 항상 다른 파일에 존재했고 이를 컴퓨터 공학에서 말하는 관심사 분리의 원칙을 지키기 위한 기초적인 사실로 받아들였기 때문에 그 당시 관점에서 이 두 가지가 함께 존재하는 JSX는 말도 안 되는 것으로 비쳤음

• 사실 리액트의 구조도 관심사 분리의 원칙을 따른다고 볼 수 있음
  당시 HTML, JS, CSS가 각기 다른 폴더와 파일로 분리되고, 파일의 역할별로 관심사가 분리되는 것에 초점이 맞춰져 있었음
  그러나 리액트의 관심사 분리는 컴포넌트 기반으로, 뉴스피드 컴포넌트의 JSX와 CSS, 사진의 JSX와 CSS, UFIdml JSX와 CSS로 나눠지는 등 컴포넌트의 역할에 따라 관심사가 분리돼 있었음

• 즉, 관심사 분리의 원칙이라는 개념하에 리액트와 기존 프로젝트가 서로 다른 방식을 채택한 차이만 있을 뿐이었음

• 일부는 리액트의 접근 방식에 흥미를 느꼈고 프로덕션 애플리케이션에 리액트를 도입하는 사람들이 생겨났음. 리액트의 개발자가 아닌 외부 개발자들이 리액트에 새로운 아이디어와 활기를 불어넣기 시작하면서 새로운 원동력을 얻기 시작했음

• 리액트 커뮤니티는 리액트가 제공하지 못한 것을 채워주기 위해 상태 관리 라이브러리, 라우터 라이브러리, 서버 사이드 렌더링 프레임워크 등이 등장하기 시작하면서 리액트는 프론트엔드 생태계에 자리 잡기 시작했음

• 리액트를 채택한 유명한 웹사이트 중 하나인 넷플릭스는 웹 사이트 빌드, 최초 상호작용에 소요되는 시간이 오래 걸리자 새로운 UI에 맞춰 새로운 웹사이트를 만들고자 모던 프레임워크 도입을 고민하기 시작

• 이에 개발자를 두 팀으로 나눠 30일 동안 각각 리액트와 백본으로 프로토타입을 만들어보기 시작하면서 리액트가 몇 가지 더 확실한 장점을 가지고 있음을 깨닫게 됐음 1. 자바스크립트 코드의 크기가 줄음 2. 상대적으로 완만한 학습 곡선 3. 빠른 기능 추가

• 이 당시 React.js Conf에서 소개된 라이브러리가 바로
  react-hot-loader, redux 등이었고 이는 리액트의 성장을 더욱 가속화했음

• 상태관리: Redux, Zustand, Recoil, Jotai
  서버 사이드 렌더링: Next.js, Remix, Hydrogen
  애니메이션: Framer Motion, react-spring, React Move
  차트: Recharts, visx, nivo
  폼: React Hook Form, Formik, React Final Form