- 4월 20일(수)
- 브라우저 렌더링 과정에 대해 설명해보세요
- 웹팩과 바벨에 대해 설명해보세요
- CSR과 SSR의 차이가 무엇인가요?
- CORS가 무엇이고 이를 처리해본 경험을 말씀해주세요
- 웹사이트 성능 최적화에는 어떤 방법이 있는지 설명해보세요
- 쿠키, 세션, 웹스토리지의 차이를 설명해보세요
웹팩 개념잡기 https://kdydesign.github.io/2017/07/27/webpack/
웹팩 써보신적 있나요 하는 질문에 대답하기
웹팩은 create-react-app이나 angular-cli에서 기본적으로 사용하기 때문에 사용해본 적은 있지만 직접 config file을 작성해본 적은 없습니다.
웹팩은 무엇인가 : build tool이며 Package Bundler이다.
build tool 중 많이 사용하는 tool
Gulp / Webpack
Gulp는 Task Runner / 웹팩은 Package Bundler (module bundler)
Package Bundler - 종속성을 가진 애플리케이션 모듈을 정적인 소스로 재생산
Task Runner - 반복 가능한 특정 작업을 자동화
Webpack은
애플리케이션을 처리할 때 필요한 모든 javascript 모듈들을 종속성 그래프로 반복적으로 작성한 다음 모든 모듈을 브라우저에서 로드 할 수 있는 하나 혹은 여러개의 Bundle로 패키지화하는 것을 뜻한다.
이 작업을 번들링이라고 한다.
웹팩의 특징
Loader를 통해 Javascript, Image file, Font, CSS 들을 하나의 모듈로 취급해줌
Entry 별로 Bundle 생성 가능
Bundle에 대한 압축 및 난독화, 소스 맵에 대한 옵션을 제공
Plug-In 사용을 통한 사용자 정의 기능 수행
비동기 I/O와 다중 캐시 레벨을 사용하기 때문에 컴파일 속도가 매우 빠름
CommonJS(nodejs)와 AMD(requires) 스펙 지원
번들링을 진행하는동안 config 파일을 설정해서 uglify나 minified등을 해줄 수 있고 cra를 사용할 경우 기본 설정이 맞춰진 상태로 나온다.
javascript가 ES6에 들어서면서 모듈 관련 스펙이 들어갔지만 모든 브라우저가 이를 지원하는 것은 아니기때문에 webpack의 도움이 필요하다. 또한 모듈로 나눠진 js파일들을 하나 또는 여러개의 작은 js 파일로 번들링 함으로써 네트워크 통신 비용도 줄어들게 된다
babel은 컴파일러 인가 ? 트랜스파일러인가
Babel은 빌드 단계에서 Javascript를 다른 언어로 변환하는 것이 아닌 어플리케이션에서 설정된 환경에 맞게 또는 현재 사용하고 있는 대중적인 브라우저 스펙 또는 호환성에 맞는 하위 버전의 Javascript로 변환한다는 의미에서 Babel은 트랜스파일러라고 할 수 있습니다.
컴파일러와 트랜스파일러에 대해 설명하자면,
컴파일러 의 경우에는 한 언어도 작성된 코드를 다른 언어로 변환하는 것으로 C 코드로 개발된 코드를 Assembly 코드로 변환하는 것과 같고
트랜스파일러 란 한 언어로 작성된 소스 코드를 비슷한 수준의 추상화를 가진 언어로 변환하는 것을 의미합니다.
바벨의 빌드 단계를 설명하자면, 파싱, 변환, 출력의 단계로 코드를 변환하는데,
파싱: 코드를 읽고, 추상 구문 트리(AST)로 변환하는 단계
변환: 추상 구문 트리(AST)를 변경
출력: 변경된 결과물을 출력
위와 같은 빌드 단계를 통해 Babel은 Javascript의 호환성 이슈를 해결합니다.
https://lihano.tistory.com/20
바벨 (Babel)
웹 개발을 하다보면 바벨(babel)이라는 단어에 대해서 많이 들어보실 수 있을 겁니다. 저도 바벨을 사용해본 경험은 있지만 이게 정확히 어떤 것인지는 잘 알지 못합니다. 그래서 이번 포스팅에서는 바벨에 대해서 이야기해보려고 합니다.
요약하자면 바벨이란 건 자바스크립트 컴파일러라고 표현할 수 있습니다. 컴파일러란 인간 수준의 고언어로 작성된 프로그램을 기계어로 된 프로그램으로 출력하는 번역기입니다. 하지만 대학교 프로그래밍 기초 강의 시간에서 배우듯이 자바스크립트는 컴파일러가 아니라 인터프리터로 동작합니다.
바벨과 웹팩의 차이 트랜스랑 컴파일러 메모
인터프리터와 컴파일러의 차이. 혹시 기억이 나지 않으신가요?
두 녀석 모두 고레벨 언어를 기계어로 변환하는 번역기인건 맞지만 그 과정에서 차이를 보이기 때문에 따로 분류됩니다. 컴파일러는 전체 소스를 파악하여 번역을 진행한다면 인터프리터는 소스코드의 각 행을 연속적으로 번역하여 실행합니다.
그럼 이게 어떤 차이를 보이게 되냐구요? 인터프리터의 특성은 4가지로 정의할 수 있습니다.
컴파일러는 전체를 한번 훑고 컴퓨터가 이해할 수 있는 기계어로 번역하는 반면, 인터프리터는 각행을 고레벨에서 중간 코드(intermediate code)로 즉각 변환&실행한다. 중간 코드는 별도의 프로그램에 의해 읽혀서 실행되어진다.
일반적으로는 컴파일러가 인터프리터보다는 실행이 빠르다.
컴파일러는 전체를 파악하여 에러를 출력하지만 인터프리터는 오류가 발생한 시점에서 그 뒤는 번역하지 않는다.
인터프리터 언어는 컴파일 언어보다 기계 종속성으로부터 자유롭다.
자바는 컴파일러와 인터프리터 모두를 사용합니다. 파이썬은 인터프리터, C C++ 언어는 컴파일 언어입니다.
이야기가 옆으로 잠시 샜지만 논제는 자바스크립트에 어째서 컴파일러 바벨이 필요한가? 입니다. 그 이유는 바벨이 고레벨 언어를 기계어로 번역하는 게 아닌, 자바스크립트로 결과물을 만들어주는 컴파일러이기 때문입니다. 이런걸 소스 대 소스 컴파일러(transpiler)라고 부릅니다.
그럼 왜 자바스크립트를 자바스크립트로 변환하는 과정이 필요한걸까요? 번거롭게. 그건 아래에서 설명하도록 하죠.
바벨(Babel)을 왜 사용할까?
이 글을 읽는 분들은 크로스 브라우징에 대해서 알고 계실겁니다. 간단한 단어로 설명하자면 다양한 브라우저에서 서비스를 제공하려는 움직임입니다. 단지 서비스의 제공 뿐만이 아니라 최적화의 문제도 포함되겠지요. 즉 호환성과 효율성에 관련이 깊은 용어입니다.
호환성 문제는 브라우저의 다양성과 기술의 빠른 발전 등에 의한 것입니다. 특히 기술의 변화가 굉장히 빠르기 때문에 최신 브라우저조차 지원하지 못하는 문법과 기술들이 출연하고 있죠. 게다가 웹 개발자라면 당연히 옛날 브라우저를 사용하는 사용자들도 고려해야합니다.
이렇게 정말 다양한 환경을 고려하는 건 쉽지가 않습니다. 이것이 사람들이 바벨을 사용하는 이유입니다. 바벨은 새로운 문법이나 타입스크리트 혹은 JSX 같이 다른 언어로 분류되는 언어들에 대해서도 모든 브라우저에서 동작할 수 있도록 호환성을 지켜줍니다. 즉, 위와 같은 기술들이 모든 브라우저에서 작동되는 하위버전의 자바스크립트 언어로 변환된다는 거겠죠.
바벨 동작은 다음 세단계로 구분됩니다.
파싱 (parsing) : 코드를 읽고 추상 구문 트리(AST)로 변환하는 단계
변환 (Transsforming) : 추상 구문 트리를 변경하는 단계
출력 (Printing) : 변경된 결과물을 출력하는 단계
사실 바벨이 담당하는 건 파싱과 출력입니다.
또 잠깐... 추상 구문 트리라는 게 뭐죠? 이건 저도 처음 들어보는 개념인데요.
추상 구문 트리란 프로그램 내에서 발생하는 기능을 나타내기 위해 만들어진 구문 구조입니다. 이는 고수준의 언어를 기계어로 변환하는 과정에서 꼭 필요합니다. 코드를 트리 구조의 데이터 스트럭쳐로 만들어냅니다. 이렇게 구조화시키면 프로그래머도, 컴퓨터도, 훨씬 파악하기 쉬워지겠죠.
그냥 제가 이해한대로 쉽게 말하자면 인간의 타이핑이 아닌 구조화된 트리로 코드를 변환시키는 겁니다. 바벨은 자바스크립트 코드를 받아서 AST를 만듭니다. 그리고 그걸 활용하여 새로운 자바스크립트 코드를 출력합니다.
그렇다면 중간의 변환은 누가 담당할까요? 바로 바벨 플러그인(plugin)이 담당합니다. 플러그인은 어떤 코드를 어떻게 변환할지에 대한 규칙을 정의합니다. 이러한 플러그인은 필요하다면 직접 만들어 쓸 수 있습니다. 그리고 플러그인들을 목적에 따라 묶어놓은 세트를 프리셋(preset)이라고 합니다.
바벨 폴리필(polyfill)
아무리 하위 자바스크립트로 변환한다고해도 한계는 있을 겁니다. 바벨을 사용한다고해서 최신 함수를 사용할 수 있는 건 아닙니다. 바벨은 다만 문법을 변환하여 자바스크립트로 변환할 뿐이니까요.
문법이 아니라 함수의 경우는 바벨로는 해결할 수가 없습니다. 브라우저 엔진이 구현하지 않는 새로운 함수라면 이를 브라우저에서 돌릴 수 있는 다른 방법을 생각해놔야 합니다. 그리고 그게 바로 폴리필이 되겠군요.
그렇다면 이 상황에 폴리필이 뭘 어쩔 수 있느냐? 폴리필은 스크립트에 사용자가 원하는 최신 함수를 추가합니다. 자바스크립트는 매우 동적인 언어이기 때문에 원하기만 하면 어떤 함수라도 스크립트에 추가할 수 있거든요. 폴리필이 이 역할을 대신하는거죠.
폴리필은 특정 기능이 지원되지 않는 브라우저를 위해 사용합니다. 바벨은 컴파일시에 실행되지만 폴리필은 런타임에 실행된다는 게 차이점이겠군요. 말그대로 구현이 누락된 새로운 기능을 메꿔주는 fill 역할을 수행합니다.
