1장. 들어가며

웹 개발의 역사

• 자바스크립트 표준, ECMAScript의 탄생

  • 크로스 브라우징 이슈(: 브라우저마다 웹 페이지가 다르게 동작함) 발생

  • 초기의 자바스크립트는 브라우저 생태계를 고려해서 작성된 것이 아니었기 때문에, 브라우저는 자바스크립트의 발전 속도 간의 차이를 따라잡지 못함

  • 이러한 문제를 해결하기 위해 자바스크립트에 폴리필과 트랜스파일 같은 개념이 등장하기도 함.

    폴리필 : 브라우저가 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드 조각이나 플러그인 (ex: core.js, polyfill.io)

    트랜스파일 : 최신 버전의 코드를 예전 버전으로 변환하는 과정 (ex: 바벨)

  • 라이브러리에 기대지 않고 크로스 브라우징 이슈를 해결하고, 모든 브라우저에 동일하게 동작하는 표준화된 자바스크립트의 필요성이 제기됨

• 웹 사이트에서 웹 애플리케이션으로의 전환

  • 웹사이트
    • 수집된 데이터 및 정보를 특정 페이지에 표시하기 위한 정적인 웹
    • 단 방향으로 정보를 제공 → 사용자와 상호 작용 X
    • HTML에 링크가 연결된 웹 페이지 모음 → 동적 업데이트 X
  • 웹 애플리케이션
    • 사용자와 상호작용하는 쌍방향 소통의 웹

• 개발 생태계의 발전

  • 대규모 웹 서비스 개발의 필요성 → 컴포넌트 단위로 개발하는 방식이 생김
  • 비동기 요청을 활용한 페이지 일부 데이터 로드 가능
  • 서비스 규모가 커짐 (데이터, UI, 디바이스 등)

  ⇒ 컴포넌트 베이스 개발(Component Based Development, CBD) 방법론 등장

  컴포넌트 베이스 개발 : 재사용할 수 있는 컴포넌트를 개발 또는 조합해서 하나의 애플리케이션을 만드는 개발 방법론

  • 컴포넌트는 다른 컴포넌트와의 의존성을 최소화하거나 없애야 함.
    • 컴포넌트 : 하나의 독립된 기능을 재사용하기 위한 코드 묶음. 런타임에서 독립적으로 배포 및 실행될 수 있음

자바스크립트의 한계

• 동적 타입 언어
  • 변수에 타입을 명시적으로 지정하지 않고 코드가 실행되는 런타임에 변수값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정됨
• 동적 타이핑 시스템의 한계
  • 자바스크립트는 관대하다.
  • 개발자의 의도와 다르게 동작할 수 있다. (ex: 숫자 a,b의 합을 구하는 함수에서 문자열의 합을 구할 수 있음)
• 한계 극복을 위한 해결 방안
  • JSDoc
    • 모듈, 네임스페이스, 클래스, 메서드, 매개변수 등에 대한 API 문서 생성 도구
    • 주석의 성격을 지님 → 강제성을 부여해 사용하기 어려움
  • protoTypes
    • 리액트에서 컴포넌트의 props 타입을 검사하기 위해 사용하는 속성
    • 전체 애플리케이션의 타입 검사를 하는데는 사용할 수 없음.
    • 리액트라는 특정 라이브러리에서만 사용 가능
  • 다트
    • 자바스크립트가 이미 자리매김한 상황에 새로운 언어의 등장 → 달갑지 않음
• 타입스크립트의 등장
  • 자바스크립트의 슈퍼셋(: 기존 언어에 새로운 기능과 문법을 추가해서 보완하거나 향상하는 것) 언어
  • 타입 에러를 사전에 방지해 안정성 보장 ← 정적 타이핑 제공, 컴파일 단계에서 타입 검사
  • 타입 자동 완성 기능으로 개발 생산성 향상
  • 협업에 유리
  • 자바스크립트에 점진적 도입 가능