github.com/baeharam/Must-Know-About-Frontend
baeharam/Must-Know-About-Frontend
:mortar_board: 취준생이라면 반드시 알아야 하는 프론트엔드 관련 지식들. Contribute to baeharam/Must-Know-About-Frontend development by creating an account on GitHub.
github.com
위 사이트 보고 따라 타이핑하면서 공부
SPA와 MPA
- SPA : 하나의 HTML 파일을 기반으로 자바스크립트를 이용해 동적으로 화면 컨텐츠를 바꾸는 방식의 웹 어플리케이션
- MPA : 사용자가 페이지를 요청할 때 마다, 웹 서버가 요청한 UI와 필요한 데이터를 HTML로 파싱해서 보여주는 방식의 웹 어플리케이션.
전통적인 방식을 사용한다면 SPA가 사용하는 렌더링 방식이 CSR이고, MPA가 사용하는 방식이 SSR이다.
CSR : 브라우저가 서버에 HTML과 JS를 로드하면 사용자의 상호작용에 따라 JS를 이용해서 동적으로 렌더링 함
- 장점
- 첫 로딩만 기다리면, 동적으로 빠르게 렌더링 되기 때문에 사용자 경험(UX)가 좋다.
- 서버에게 요청하는 횟수가 적기 때문에 서버 부담이 덜하다.
- 단점
- 모든 스크립트 파일이 로드될 때 까지 기다려야한다. (리소스를 청크단위로 묶어서 요청할 때만 다운받게 하는 방식으로 완화시킬 수는 있지만 완전히 해결되는건 아님.)
- 검색엔진의 검색 봇이 크롤링을 하는데 어려움을 겪기에 SEO의 문제가 있다.
SSR
SSR에선 브라우저가 페이지를 요청할 때 마다 해당 페이지에 관련된 HTML, CSS, JS 파일 및 데이터를 받아와서 렌더링 시킨다.
- 장점
- 초기 로딩 속도가 빠르기 때문에 사용자가 컨텐츠를 빨리 볼 수 있다.
- JS를 이용한 렌더링이 아니기 때문에 검색엔진 최적화가 가능하다.
- 단점
- 매번 페이지를 요청할 때 마다 새로고침 되기 때문에 사용자 경험이 SPA에 비해 좋지 않다.
- 서버에 매번 요청을 하기 때문에 서버의 부하가 커진다.
브라우저의 렌더링 원리
브라우저가 호면에 나타나는 요소를 렌더링 할 때, 웹킷이나 게코 등과 같은 렌더링 엔진을 사용함. 렌더링 엔진이 HTML, CSS, JS로 렌더링할 때 CRP(Critical Rendering Path)라는 프로세스를 사용해서 다음 단계들로 이루어진다.
1. HTML 파싱 후, DOM 트리 구축
- DOM 트리는 완전히 구문 분석된 HTML 페이지의 Object 표현
2. CSS 파싱 후, CSSOM 트리 구축
3. JS 실행 (HTML 중간에 스크립티가 있다면 HTML 파싱이 중단됨)
4. DOM과 CSSOM을 조합하여 렌더 트리 구축
5. 뷰 포트 기반으로 렌더트리의 각 노드가 가지는 정확한 위치와 크기 계산
6. 계산한 위치/크기를 기반으로 화면에 그림.
즉 DOM트리 구축을 위한 HTML, CSS 파싱 -> 렌더 트리 구축 -> 렌더 트리 배치 -> 페인팅 순서
JS엔진이 코드를 실행하는 과정
자바스크립트를 실행하기 위해 자바스크립트 엔진이 필요하고, 웹 브라우저는 자바스크립트 엔진을 내장하고 있다. 브라우저마다 엔진의 종류가 다르지만 코드를 실행하는 방식은 비슷하기 때문에 보통 어ㄸ허게 실행하는지 알아두는 것이 좋다.
1. 자바스크립트 소스 코드를 파싱해서 AST(추상 구문 트리)로 변환한다.
2. 인터프리터는 AST를 기반으로 바이트코드를 생성한다.
3. 인터프리터가 바이트코드를 실행할 때, 자주 사용되는 함수 및 타입 정보 등이 있는 프로파일링 데이터와 같이 최적화 컴파일러(Optimized compiler)에게 보낸다.
4. 최적화 컴파일러는 프로파일링 데이터를 기반으로 최적화된 코드를 생성한다.
5. 하지만, 프로파일링 데이터 중에 잘못된 부분이 있다면 최적화 해제르 ㄹ하고 다시 바이트코드를 실행해서 이전 동작을 반복한다.
BOM과 DOM
BOM
브라우저의 창이나 프레임을 프로그래밍적으로 제어할 수 있게 해주는 객체모델. 이를 통해서 브라우저의 새 창을 열거나 다른 문서로 이동하는 등의 기능을 실행시킬 수 있다. (window, location, navigator, document, screen, history 등)
DOM
웹 페이지를 프로그래밍적으로 제어할 수 있게 해주는 객체모델. 최상위 인터페이스는 node이고, 텍스트와 주석들까지도 DOM 트리에 포함됨. DOM을 다루기위한 getElementsById, querySelector 등과 같은 DOM API를 브라우저가 제공함.
모듈 번들러와 트랜스파일러
모듈 번들러
현대의 프론트엔드 개발은 모듈 단위로 파일을 엮어서 개발하는 방식이다. 즉 모듈은 서로 의존성을 띄고 있는데 이런 점에서 다음과 같은 문제들이 생긴다.
- 수많은 모듈들의 순서를 어떻게 처리할 것인가? (의존성 처리)
- 모듈이 많아질수록 HTTP 요청이 많아질텐데 이로인한 오버헤드는 어떻게 해결할 것인가?
- ES6+ 스펙의 코드를 어떻게 처리할 것인가.
위 문제들을 해결하기 위해 등장한 것이 모듈 번들러이다. 각각의 모듈 의존성을 해결하여 하나의 자바스크립트 파일로 만듦과 동시에 ES6+ 스펙을 ES5로 변환까지 해주는 도구이다. 이미지 압축과 최소화 등의 여러가지 기능도 제공한다. 대표적으로 웹팩.
트랜스파일러
트랜스파일링이란? 특정 언어로 작성된 코드를 비슷한 다른 언어로 변환시키는 행위를 말하며 이를 해주는 것이 트랜스파일러이다. 트랜스 파일러가 필요한 이유는 모든 브라우저가 ES6+ 기능을 제공하지 않기 때문에 이를 ES5 코드로 변환시키는 과정이 필요하다. 트랜스파일러는 이 작업을 수행해준다. 사실 ES6+의 기능 뿐만 아니라 리액트의 JSX를 자바스크립트 코드로 변환시킨다거나 타입스크립트를 자바스크립트로 변환시키는 등의 역활도 트랜스파일러의 기능 중에 하나이다. ES6+나 JSX를 변환시키는 트랜스파일러로는 바벨이 있으며 타입스크립트로 변환시키는 도구로는 타입스크립트 트랜스파일러가 있다. 보통 프론트엔드 프레임워크 및 라이브러리를 사용해서 개발할 때 모듈 번들러에 트랜스파일러를 추가해서 사용하는 방식을 사용한다.
CI와 CD
CI ( Continuous Integration, 지속적 통합 )
CI는 빌드와 테스트를 자동화해서 공유 저장소에 병합시키는 프로세스를 뜻한다. git과 같은 버전관리 시스템을 사용할 때 여러명의 개발자가 하나의 공유 저장소를 사용하는 경우가 많다. 이렇게 되면 새로운 코드의 변경 사항이 저장소에 통합되지 않을 경우 서로 충돌할 수 있다. 따라서 빌드/테스트 자동화부터 코드의 일관성을 제공하기 때문에 지속적으로 통합한다는 용어를 사용하는 것이다.
예시
개발자가 로컬에서 코드를 수정하고 깃헙에 푸시 -> CI 도구에서 변경된 코드에 대한 빌드와 테스트를 수행하고 결과를 피드백해줌.
CD ( Continuous Delivery/Deploy, 지속적 전달/배포)
CD는 CI의 빌드/테스트를 통해서 정상적으로 수행됨을 확인하면 이는 배포를 수동으로 하느냐 자동으로 하느냐에 따라 2가지로 나뉜다.
- 지속적 전달 : 프로덕션 배포를 위한 상태가 되고 배포 자체는 수동으로 실행한다. 개발팀과 비즈니스 팀간의 커뮤니케이션 부족 문제를 해결
- 지속적 배포 : 프로덕션까지 자동으로 배포한다. 어플리케이션의 제공 속도를 증가시킨다.
CI/CD 서비스 - Jenkins
CSS 애니메이션 vs JS 애니메이션
웹 사이트에 애니메이션 효과를 부여할 때 CSS의 transition / animation 속성을 사용할 수 있고, JS의 setInterval() / requestAnimationFrame()을 사용할 수 있다. 각각 어떤 특징이 있고 장단점이 있는지 알아두자.
CSS 애니메이션
일반적으로, 마우스를 올렸을 때 혹은 메뉴 버튼의 전환과 같은 간단하게 처리하는 애니메이션의 경우 CSS로 처리함. 예를들어, 200 크기의 정사각형을 왼쪽 위에서 오른쪽 아래로 350px 움직이게 하는 애니메이션을 구현한다고 하면, transform 의 translate 를 사용해서 구현할 수 있다. 하지만 이를 JS로 구현하기 위해선 setInterval을 통해서 계속해서 style.top 과 style.left 속성을 변화시켜줘야 한다. 이렇게 되면 이 속성은 브라우저의 렌더링 과정에서 reflow(layout)를 발생시키기 때문에 애니메이션이 부자연스럽게 끊기는 듯한 느낌을 받게 된다. 이런 점에서 바닐라 JS로 애니메이션을 구현하는 것보다 CSS로 구현하는 것이 좋다고 할 수 있다. 이외에도 다양한 장점들이 있으며 정리하자면 다음과 같다.
- 반응형으로 애니메이션을 구현하기에 유용한데, 미디어 쿼리로 애니메이션을 적용하면 된다.
- 외부 라이브러리가 필요하지 않다.
- CSS 자체가 선언형이기 때문에 어떤 요소가 애니메이션을 가져야 한다는 직관적인 표현이 가능하다
- 메인 쓰레드가 아닌 별도의 컴포지터 쓰레드에서 그려지기 때문에 메인 쓰레드에서 작업하는 JS보다 효율적이다.
JS 애니메이션
CSS로 처리하기에는 훨씬 복잡하고 무거운 애니메이션 작업들을 효율적이고, 세밀하게 다루기 위해 사용한다. 바닐라 자바스크립트로 구현할 경우 위에서 살펴본 바와 같이 계속해서 요소의 위치를 재계산하기 때문에 비효율적이며 사용자 눈에 가장 부드러운 60fps가 유지되지 않는다. 이 때문에 RAF(RequestAnimationFrame) API가 등장했고 구현방식은 동일하지만 60fps를 보장할 수 있게 되었다. 이 외에도 외부 라이브러리인 Velocity.js 와 GSAP 같은 라이브러리를 통해서 성능 좋은 애니메이션을 구현할 수 있다. 보통 복잡한 애니메이션을 구현하려고 하면 외부 라이브러리를 사용할텐데 이것이 CSS에 비해 가지는 장점은 다음과 같다.
- 요소의 스타일이 변하는 순간마다 제어할 수 있기 때문에 애니메이션의 세밀한 구성이 가능해진다.
- GPU를 통한 하드웨어 가속을 제어할 수 있다. 이는 CSS의 특정 속성으로 인한 가속을 막아주는데, 하드웨어 가속이 모바일에서 성능저하를 발생시킬 수 있기 때문에 이런 면에선 좋다.
- 브라우저 호환성 측면에서 transition / animation 속성보다 뛰어나다.
'공부' 카테고리의 다른 글
| CSS (0) | 2020.11.28 |
|---|---|
| HTML (0) | 2020.11.28 |
| 웹팩 바벨 요약 (0) | 2020.11.25 |
| 토익 문법 정리 - 접속사 (0) | 2020.09.01 |
| 토익 문법 정리 - 동명사 / to 부정사 / 분사 (0) | 2020.09.01 |
