들어가며
- 왜 리액트인가
-
명시적인 상태 변경: 리액트는 단방향 바인딩만 지원한다. 단방향 바인딩이란 말 그대로 데이터의 흐름이 한쪽으로만 간다는 것이다. 상태가 변화했다면 그 상태 변화를 명시적으로 일으키는 함수만 찾으면 된다.
-
단방향 바인딩은 항상 변화를 감지하고 업데이트하는 코드를 매번 작성해야 하며, 이에 따라 코드 규모가 증가하는 등의 단점이 있다. 여기서 말하고자 하는 바는 단방향 바인딩의 특징은 양방향 바인딩에 비해 데이터 흐름의 변화가 단순하기 때문에 코드를 읽기가 쉽고 버그를 야기할 가능성이 비교적 적다는 뜻이다.
- 리액트의 역사
-
페이스북은 최대한 서버에서 렌더링하는 기술을 사용했고, 자바스크립트 번들의 크기를 줄이는 데 오랜 기간 심혈을 기울였다. 자바스크립트 코드의 크기가 늘어날수록 이를 다운로드하고, 파싱하고, 실행해야 하는 브라우저의 부담이 커지는 것은 당연했기 때문이다. 따라서 자바스크립트는 반드시 필요한 곳에서만 제한적으로 사용하고자 노력했다. 그런 노력에도 불구하고 자바스크립트 코드는 커질 수밖에 없고, 서버 렌더링이 처리할 수 있는 규모에는 한계가 있을 수밖에 없었다.
-
타임라인에서는 자신의 상태를 업로드 할 수 있고, 여기에 다른 사람들의 댓글이 추가되는 것을 실시간으로 확인할 수 있다. 그런데 이러한 작업이 모두 서버 렌더링으로만 작동한다고 가정해 보자. 사용자가 글을 하나 올릴 대마다 매번 새로운 페이지를 보여주기 위해 서버에서 렌더링하고, 당연히 이러한 작동은 브라우저 전체가 다시 로딩되어 전체 화면이 깜빡이거나 느리게 작동하는 것처럼 보일 것이다. 타임라인뿐만 아니라 페이스북의 여러 페이지는 실시간성을 강조하는 기능이 곳곳에 추가돼 있었다. 페이스북 개발 팀이 자바스크립트 번들 사이즈를 최대한 줄이고 싶었지만 이러한 다양한 요구사항과 기능으로 인해 자바스크립트에 의존하는 것을 피할 수 없는 일이었다.
- 페이스북 팀의 대안으로 떠오른 리액트
- 처음부터 리액트로 만들어진 인스타그램, 그리고 기존 페이스북의 거대한 PHP 애플리케이션 중 부를 리액트로 조금씩 대체하기 시작하면서, 페이스북 개발자들은 리액트에 대한 자신감을 조금씩 얻기 시작했다. 이와 동시에, 리액트를 오픈소스로 공개하고자 하는 노력도 함께 이루어지고 있었다. 과거 BoltJS 사례와 비슷하게 페이스북은 많은 것을 오픈소스로 공개했지만 제대로 관리하지 않아 방치된 프로젝트들이 많았다. 이를 개선하고자 리액트의 경우에는 인스타그램 팀에 제공했던 것처럼 문서화에 심혈을 기울이기 시작했다. 그리고 이러한 리액트를 공개할 무대로 JSConf US를 선택했고, 여기에서 리액트와 함게 embedded XML인 JSX도 함께 공개했다.
