1. Webkit을 브라우저 작동 원리를 공부하다 알게 되었는데 이는 브라우저 엔진이다. 아래와 같은 코드를 원리도 모르고 사용했었다. 브라우저별 그 브라우저 엔진을 사용하는 이유는 뭘까? 그리고 이 코드를 통해 어떤 효과를 얻을 수 있을까? 크로스 브라우징과 관련 있을 듯

브라우저 엔진의 정의와 종류, 역할
우선 브라우저 엔진은 렌더링 엔진, 레이아웃 엔진으로도 불린다.
렌더링 엔진의 역할은 요청 받은 내용을 브라우저 화면에 표시하는 일.
보통 자신의 브라우저에서 사용할 엔진을 자체적으로 개발하거나, 기존에 개발된 엔진을 포크시켜 개발하여 사용한다.
오페라 브라우저에서 사용하는 Presto(프레스토), KHTML엔진에서 *fork하여 애플에서 개발한 웹키트(Webkit)는 사파리와 구글 크롬이 사용중인데 애플과 구글은 엔진을 서로 fork 하면서 파편화가 진행되었습니다. 애플은 웹킷2, 구글은 블링크. IE에서 사용하는 트라디던드, 엣지에서 사용하는 EdgeHTML, 태즈먼은 맥용 IE에서 사용한다.

*포크(fork) 또는 소프트웨어 개발 포크, 프로젝트 포크는 하나의 개발 소스를 복사하여 독립적인 새로운 소프트웨어를 개발하는 것이다.

Vendor Prefix 벤더 프리픽스
CSS prefixes
-webkit- 사파리나 크롬에서 사용하는 웹킷 엔진 기반의 웹 브라우저에서 사용
-moz- 파이어폭스 웹 브라우저에서 사용
-o- 오페라 웹 브라우저에서 사용
-ms- IE에서 사용
더 많은 브라우저 프리픽스는 여기서 확인할 수 있다.

크로스 브라우징을 해야하는 이유
브라우저마다 렌더링 엔진이 다르기 때문에 크로스 브라우징(브라우저 호환성)을 작업마다 해줘야한다.
브라우저마다 작동하지 않는 HTML5, JS 코드가 존재할 수 있고, 해석이 안되는 CSS 코드, 브라우저별 버그들이 존재하고, 브라우저 자체 스타일 시트가 다르기 때문.

✅ 참조
브라우저 엔진의 종류
브라우저 엔진의 정의
크로스 브라우징
벤더 프리픽스

2. 실무에서 JQuery를 사용했었다. 개발자들은 JQuery를 쓰는 것에 회의적이다. 안쓰는 이유는 뭘까? 그리고 바닐라 JS와 순수 자바스크립트를 쓰는 이유? 다른 점?

JQuery는 웹사이트에 JS를 쉽게 활용할 수 있도록 도와주는 오픈 소스 기반의 자바스크립트 라이브러리. 제이쿼리의 사용률은 여전히 높으나 개발자들 사이에서의 위상은 예전 같지가 않다. 그 이유는 다음과 같다.

(1) 웹표준 API의 확장
제이쿼리와 같은 라이브러리를 사용해야만 가능했던 기능을 브라우저 자체 기본 API로 제공하게 됨. 예로는 Fetch API. - 이에 대해선 조금 후에 자세히 알아보자.

(2) 웹브라우저 환경의 변화
제이쿼리가 본격적으로 사용되기 시작한 2007년, IE가 전세계 웹 브라우저 시장의 60%이상 점유하는 상황이었다. 업데이트가 느리고 데스크톱 기반의 윈도우 환경에서 제이쿼리는 필수였다. 하지만 2008년 데스크톱 OS뿐만 아니라 모바일 OS도 지원하는 크롬이 등장하고 2013년 이후 시장 점유율 1위를 지키고 있다. 성능이 우수한 렌더링 엔진을 탑재하고 웹 표준을 신속히 반영했다. 제이쿼리와 같은 라이브러리 없이 양질의 웹 애플리케이션 구현이 가능해진 것.

(3) 가상 돔(Virtual DOM)을 사용하는 라이브러리 등장
웹페이지는 브라우저상 돔이라는 표준 형식으로 파싱되어 표현되고, 동적 웹을 구현하기 위해선 돔 조작은 필수다. 하지만 돔 조작 발생시 배치나 레이아웃 표시에 많은 연산이 발생되어 브라우저 성능 최적화가 어려워졌음. 이로 자바스크립트 라이브러리 중 하나인 리액트는 가상 돔을 채용하여 대중화시켰다. 이후 등장한 뷰 등의 프레임워크와 라이브러리도 가상 돔을 적극 채용함.
가상 돔을 사용하는 라이브러리가 많아질수록 돔을 직접 조작하는 제이쿼리의 필요성이 줄어듬.

바닐라 JS란?
라이브러리나 프레임워크를 쓰지 않은 순수 자바스크립트.
이전에 IE에서 자바스크립트 뿐만 아니라 웹과 관련된 표준 명세를 따르지 않아 웹 개발에 있어 최대 난제였다. 이런 이유로 크로스 플랫폼이 가능한 JQuey를 사용해서 쉽게 해결했었다. 하지만 지금의 모던 웹 개발 환경에서는 발전된 ECMAScript 명세와 최신 브라우저를 바탕으로 표준 js만으로도 쉽게 개발을 할 수 있게 되어 순수 자바스크립트(Vanilla JS)의 중요성이 화두가 되기 시작했다.

프레임워크와 라이브러리를 중시하고 남용하기보다 목적에 맞게 순수 자바스크립트를 베이스로 활용해보는 것이 좋은 방향일 것.

✅ 참조
제이쿼리의 현재와 미래
바닐라 자바스크립트란 무엇이고 왜 필요한가

3. Repaint, Reflow 최소화를 위해 CPU가 처리할 부분을 GPU로 넘기기 위해 width 등의 속성대신 transform이랑 opacity를 사용한다는 부분을 알게되었는데 CPU 사용과 GPU 사용의 정확한 구조와 차이가 궁금하고, 그리고 transform이랑 opacity 말고도 gpu를 사용할 수 있는 css 속성이 있을까?

중앙 처리 장치(CPU)와 그래픽 처리 장치(GPU)는 둘다 아주 중요한 기본적인 컴퓨팅 엔진이다. 둘다 실리콘 기반 마이크로프로세서이고 둘다 데이터를 처리합니다. 하지만. 아키텍처가 다르며 만들어진 용도가 다르다.

CPU는 보통 컴퓨터의 뇌로 간주. 컴퓨터 및 운영체제에 필요한 명령과 처리를 실행하므로 모든 현대 컴퓨팅 시스템에 필수적인 요소. 프로그램의 실행 속도를 결정하는 데도 중요하게 작용.
다양한 워크로드, 대기 시간이나 코어당 성능이 중요한 워크로드에 적합. 강력한 실행 엔진으로 코어 수가 적고 개별적 작업과 신속한 작업 처리에 집중. 연속적인 컴퓨팅이나 DB 실행과 같은 작업에 적합.

GPU는 더 작고 보다 전문화된 코어로 구성된 프로세서. 여러 개의 코어가 함께 작동하므로, 여러 코어로 나누어 처리할 수 있는 작업의 경우 GPU가 엄청난 성능 이점을 제공합니다.
특정 3D 렌더링 작업 속도를 단축하기 위해 개만된 전문 ASIC로 시작, 최신 인기 게임의 그래픽과 지주얼, 최근에는 범용적인 병렬 프로세서로도 발전.

조건에 맞는 css 속성은 transform과 opacity뿐이다. CSS 애니메이션은 CPU를 사용하는 방식과 GPU에 맡기는 방식으로 나뉜다. 애니메이션 기능을 오로지 GPU에 맡긴다는 것은 기하 구조를 계산하고 그려주는 reflow/repaint과정을 CPU에서 거칠 필요가 없다는 뜻이다.

(1) top, left 값을 수정하여 구현하는 애니메이션 : reflow/repaint 필요!

  • 브라우저 화면 크기에 영향받는 vh, vw 등의 속성을 top/left 값에 사용할 수 있으므로 reflow/repaint 과정이 필요하다.

(2) Transform, opacity 값으로 얻는 애니메이션 : reflow/repaint 불필요

  • 컴포넌트가 위치한 환경과 관련이 없는 속성들이라 GPU에게 애니메이션이 넘겨진다.

✅ 참조
CPU와 GPU
CSS GPU 애니메이션 제대로 하기
효율적인 애니메이션

4. HTML을 파싱할 때와 CSS를 파싱할 때 공식 작성 명세의 차이가 있었다. HTML이 유연하다는 것에 대해 좀 더 알아봐야겠다. 그리고 HTML과 CSS를 명세해놓은 공식 사이트는 어떤 걸 참고하는 것이 좋을까? MDN? W3C? 한국어로 접할 수 있는 사이트는 없을까?

HTML5도 공식 명세가 있다. 다만 일반적인 상향식, 하향식 파싱이 불가한 이유는 유연함 때문이다.

  1. HTML은 암묵적으로 태그에 대한 생략이 가능하다. 가끔 시작 또는 종료 태그 등을 생략한다. 전반적으로 뻣뻣하고 부담스러운 XML에 반하여 HTML은 "유연한" 문법이다.
  2. 잘 알려져 있는 HTML 오류에 대해서 브라우저에서 미리 필터링을 한다.
    (HTML을 파싱하는 도중 어떠한 에러가 발생한다면, 브라우저는 자체적으로 에러를 복구하려 합니다.)
  3. 변경에 의한 재파싱, 일반적으로 소스는 파싱하는 동안 변하지 않지만 HTMl에서 document.write 를 포함하고 있는 스크립트태그는 토큰을 추가할 수 있기 때문에 실제로는 입력과정에서 파싱이 수정된다.
    (쉽게 설명하면 🔽)
  • 파싱 과정이 중단될 수 있다는 것, 파싱 도중 <script>, <link> 같은 외부 태그를 만나게 되면 HTML 파싱을 즉시 중단한다. 그리고 해당 태그의 해석을 실행한다. 만약 해당 태그가 외부 파일을 참조하고 있다면 다운로드를 한 후 해석을 시작.
  • <script>에 DOM을 직접 수정할 수 있는 내용이 있을 수도 있음. Document.write()같은 API를 사용하면 HTML을 파싱하고 있는 도중에도 DOM 엘리먼트를 동적으로 삽입 가능.이로 인해 외부 컨텐츠를 해석하고 실행하기까지 HTML의 파싱은 중단됨. *예측 파싱 기법을 이용해서 별도 스레드에서 불러오기도 함.
  • 재시작(Reentrant) HTML의 파싱 과정은 어떠한 외부의 요인으로 인해 방해받을 수 있음.파싱 중간에 외부 요인으로 인해 DOM이 추가, 변경, 삭제 될 수 있다.

✅ 참조
HTML 파싱
브라우저 내에서 사용하는 알고리즘
브라우저 동작 과정
HTML - MDN
HTML - W3C School
HTML - W3C
CSS - W3C
CSS - MDN

5. HTML과 CSS를 좀더 깊이 있게 배울 수 있는 방법은 무엇일까? 단순히 태그와 속성값 등을 외우기보다 접근할 수 있는 다른 방법?

왜 이것을 배우는 지에 대해 생각해보기, 실무에 적용시킬 방법 고민해보기.
그 기술을 왜 사용해야하는지 , 내부적으로 어떤 원리로 동작하는 건지, 이 기술을 잘 사용하려면 어떻게 해야하는지
스스로 공부하는 법 터득하기. 공부 루틴같은
배운 것 면접 질문시 읊을 수 있도록 이해하고 기억하기.

공부 방법에 대해 따로 포스팅을 써야겠다.

0개의 댓글