hyungju-lee

1. 리액트를 선호하는 이유

1.1 명시적인 상태 변경

  • 리액트는 단방향 바인딩만 지원한다. 단방향 바인딩이란 말 그대로 데이터의 흐름이 한쪽으로만 간다는 것이다.
    이와 반대되는 용어는 Angular의 양방향 바인딩이다.
    양방향으로 바인딩되면 뷰의 변화가 컴포넌트에 영향을 미칠 수도, 반대로 컴포넌트의 상태가 변경되면 뷰의 상태도 변할 수 있다.
    양방향 바인딩은 단방향이 제공할 수 없는 편리함을 제공한다.
    그러나 코드의 규모가 커질수록 이 같은 상태의 변화가 무엇으로 인해 일어났는지 파악하기 어려워진다.
    리액트의 상태 변화는 '단방향'으로, 그리고 '명시적'으로 이뤄진다.
    상태가 변화했다면 그 상태 변화를 명시적으로 일으키는 함수만 찾으면 된다.
    이러한 리액트의 명시적인 상태 업데이트는 많은 개발자들에게 간단함과 유연함을 제공한다.
// Angular의 경우 input의 입력으로 name이 변경되거나,
// AppComponent 클래스 내부에서 직접 name을 변경할 수 있다.
// name이 변경된 이유를 알고 싶다면 template이나 클래스 내부에서
// name을 변경하는 곳을 다 찾아봐야 한다.
import { Component } from '@angular/core'

@Component({
    selector: 'app-root',
    template: `<input type="text" [(ngModel)]="name" />`
})

export class AppComponent {
    name = ''
}

// 리액트의 경우 name이 변경되는 경우는 setName이 호출될 때 뿐이다.
// name이 변경된 이유를 찾고 싶다면 setName을 호출하는 곳을 찾으면 된다.
function App () {
    const [name, setName] = useState('')
    
    function onChange(e) {
        setName(e.target.value)
    }
    
    return <input type="text" value={name} />
}
  • 물론 그렇다고 양방향 바인딩이 항상 나쁘다는 것은 아니다.
    단방향 바인딩은 항상 변화를 감지하고 업데이트하는 코드를 매번 작성해야 하며, 이에 따라 코드의 규모가 증가하는 등의 단점이 있다.
    여기서 말하고자 하는 바는 단방향 바인딩의 특징은 양방향 바인딩에 비해 데이터 흐름의 변화가 단순하기 때문에 코드를 읽기가 쉽고 버그를 야기할 가능성이 비교적 적다는 점이다.

1.2 JSX(JavaScript XML)

  • Angular는 뷰를 표현하기 위해 문자열 탬플릿(string template)을 사용한다.
    그리고 Angular 디렉티브라고 해서 ngIf처럼 Angular에서만 사용되는 전용 문법을 익혀야 했다.
    하지만 리액트는 HTML에 자바스크립트 문법을 더한 JSX를 사용하는데, 이는 기존에 알고 있는 자바스크립트 문법에 HTML을 약간 가미한 수준이며, 고유의 몇 가지 특징만 이해한다면 손쉽게 JSX 코드를 구현할 수 있다.
    다음은 조건부 렌더링을 구현하는 Angular 코드와 리액트 코드를 비교한 것이다.
// Angular
// 추가적인 *ngIf의 존재를 알고 있어야 한다.
<div *ngIf="condition">Content to render when condition is true.</div>

// 리액트
// 자바스크립트 문법 친화적이며, null이 아무것도 렌더링하지 않는다는 점
// 자바스크립트 문법을 {}로 감싸야 한다는 사실만 알면 된다.
// 무엇보다 JSX는 리액트 외에서도 사용할 수 있다.
{condition ? <div>Content to render when condition is true.</div> : null}

1.3 비교적 배우기 쉽고 간결함

  • 앞서 2가지 특징이 결합되어 리액트를 처음 접하는 사람들도 HTML과 자바스크립트에 대해서 어느 정도만 알고 있다면 빠르고 쉽게 컴포넌트와 웹페이지를 만들 수 있다.
    처음 접하는 사람들도 비교적 손쉽게 리액트 기반 프로젝트를 할 수 있어, 프론트엔드 개발을 처음 시작할 때 대체로 선호되는 편이다.
    그러나 개발 초기에는 쉽지만 이를 완벽히 이해하고 성능을 최적화하는 것은 상대적으로 어려운 축에 속한다.
    Vue나 최근에 나온 Svelte 같은 프레임워크와 비교했을 때 프레임워크를 자유자재로 다루기까지 드는 시간과 노력을 고려한다면 리액트는 비교적 난이도가 있는 편이다.

1.4 강력한 커뮤니티, 그리고 메타(이전의 페이스북)

리액트는 Angular와는 다르게 단순히 UI를 위한 라이브러리로만 작동함으로써 그 역할에 제한을 두고 그 외의 모든 것에 자유도를 두었다.
개발자들은 리액트를 기반으로 다양한 것을 시도해볼 수 있었고, 그만큼 리액트는 커다란 커뮤니티를 얻을 수 있게 됐다.
그리고 이 커뮤니티는 내부에서 직접 겪은 이슈와 문제를 공유하면서 리액트를 사용하는 사람들이 같은 어려움을 겪지 않도록 빠르게 도와주는 역할도 할 수 있었다.

또한 리액트 핵심 개발을 메타가 적극 지원함으로써 다소간의 우여곡절을 겪었음에도 10여 년 동안 꾸준히 발전할 수 있었다.
바벨(Babel)과 같은 초대형 오픈소스 프로젝트도 재정난을 겪는 것을 보면 역설적이지만 오픈소스가 빠르고 안정적으로 성장할 수 있기 위해서는 중심이 되는 메인 스폰서의 역할이 중요하다.
덕분에 리액트는 이러한 메타를 등에 업고 꾸준히 성장해 올 수 있었다.

물론 리액트는 단순히 현재 가장 많은 사람들이 웹 개발을 할 때 사용하는 라이브러리일 뿐, 가장 완벽하다거나 가장 빠르다거나 가장 합리적이라고 말하는 것은 절대 아니다.
프론트엔드 커뮤니티에는 리액트에 대해 부정적인 의견을 가진 개발자도 많고, Svelte나 Vue, 혹은 또 다른 무언가를 대안으로 주장하는 개발자들도 많다.

그럼에도 불구하고 만약 프론트엔드 개발을 고민하고 있고, 가장 대중적으로 웹사이트를 개발하고 싶다면 리액트는 적절한 선택이 될 것이다.
수많은 커뮤니티에서 이미 다양한 기능을 개발해 참고할 만한 자료도 많고, 커뮤니티도 활발하며, 무엇보다 채용시장과 기업에서도 매우 호의적이다.