1월 13일

이종현·2023년 1월 14일
0

회고

목록 보기
2/42

멘토가 질문을 던졌을 때 우리는 보통 답을 하기가 어렵다. 그만큼 본질을 물어보는 질문이 많다는 것이다.

깊게 공부하지 않았다는 것이고.. 그렇지만 멘토링은 거기서 끝나지 않는다. 멘토는 질문에 대한 찾는 과정에서 어떤 키워드를 검색해서 같이 참고하면 좋을지 제안해준다.

그 부분이 멘티 입장에서는 도움이 정말 많이 되는 것 같다.

한 개의 개념을 여기까지만 알고 가면 될까? 라는 생각이 들었을 때 키워드를 보고 그 키워드에 대해서 공부하다 보면 애초에 처음 질문에 대한 지식과 연결되어 지식의 확장이 일어난다.

현재 내가 나름대로 질문을 분류해서 하나씩 답을 찾아나가는 과정이다.


  • ECMAScript, 단체에서 준수해야 한다. 어떻게 스펙들이 정해지는 지..
  • 자바스크립트는 하위 버전을 버릴 수 없는 이유?
  • 노드 버전은 왜 다른지? (다시 한 번 물어봐야 할 것 같음..)


  • script 태그의 위치.. (defer, async)
    • JavaScript는 태그 맨 아래에 넣는다. 태그 안에 있다면 랜더링을 멈추고 JavaScript를 읽기 때문에 화면 랜더링이 오래걸릴 수 있다.
      • defer처럼 작동하게 하기 위해서 파싱이 전부 끝날 때 까지 기다리기 위해서 script 태그를 맨 밑에 넣었던 걸까?
      • 그렇다면 defer도 body태그 밑에다가 넣는 것보다는 조금 더 빨리 볼 수 있을 뿐이지, 그것도 결국 js에 의존적이라면 느리게 보게되는 건 비슷한 거 아닌가?
    • 스크립트를 실행할 때는 HTML 파싱이 중단되던데 같이 될 수는 없는건가? 이유는?
      • DOM 트리가 생성되기전에 자바스크립트가 생성되지도 않은 DOM의 조작을 시도할 수 있다.
      • 파싱이란 구문분석인데.. 파싱이 끝나야 DOM tree를 형성하는 거지, 랜더트리를 생성하는 과정이 파싱이 아니지 않나?
      • DOM tree와 CSSOM트리는 head태그 안에 link태그를 선언했을 때 병렬적으로 렌더트리가 생성된다는데 그렇다면 body태그 안에 있을 때는 그렇지 않은 건가? 가령 맨 밑에 선언한다면 DOM tree가 형성된다면 CSSOM트리가 형성되는 것이고, 위에 선언한다면 CSSOM트리가 형성되고, DOMtree가 형성되는 건가? 아니면 애초에 이런 질문 자체가 근본적으로 틀린 것인가? CSS란 애초에 HTML을 꾸며주는 건데, DOMtree가 형성되어 있어야 CSS도 동작이 가능한 것 아닐까?
      • script태그의 위치에 따라 렌더트리가 형성되기도 전에 자바스크립트 파일이 서버에서 불려와 작동될 수도 있다. body태그 사이 맨 앞이나 head태그 안에 async로 선언했을시, 렌더트리가 형성되기 전에 작동할 수도 있다. 그렇기 때문에 body태그 안에 맨 뒤나,defer로 선언해야 한다.
      • 파싱이란? 구문 분석이고, 파싱이 끝나야 DOMtree가 형성되는 건지? 파싱 자체가 렌더트리까지 형성하는 걸 포함하는 개념인지?
  • 스크립트 블로킹
    • script태그를 어디에 위치하느냐, 그리고 async, defer를 어디에 두느냐, (자바스크립트 파일에서 비동기적으로 코드를 짜느냐, 동기적으로 코드를 짜느냐에 관련해서는 스크립트 블로킹이랑 상관이 없는걸까? 실제로 비동기적이지 않고 동기적이라면 렌더트리가 다 형성된 뒤에 동작할 것이 아닌가?) 에 따라 렌더트리가 형성되기도 전에 자바스크립트가 동작하게 되서 컨텐츠가 뒤늦게 보이게 되는 현상, 브라우저가 제어권을 가지지 않은 상태, 블로킹 상태가 될 수 있다. (자바스크립트 파일의 로딩이 느릴 때? (어떤 경우가 있을까? 파일의 크기가 크거나? 또?)
    • defer는 블로킹이 일어날 수 없는가? (렌더트리를 모두 생성한 뒤, 자바스크립트 코드를 불러온다면.. 특정 코드를 불러올 때 너무 오래걸릴 일은 없지 않을까? 렌더트리를 형성하는 과정에서도 오래걸리는 경우가 있는가?)
    • Web workers. worker라는 별도의 스레드를 만들어서, 시간이 오래걸리는 작업은 worker가 처리하게 한다
      1. DOM에 접근할 수 없다.단순히 숫자 계산은 가능했지만, UI를 업데이트 하는 작업은 불가능하다.
      2. worker 안에서 실행되는 코드는 차단되지는 않지만 동기적으로 실행된다. 이렇게 되면 함수를 사용할 때 문제가 생긴다.
  • 리플로우, 리페인트에 대해 (Layout) Reflow, Repaint
    • 리페인트가 일어나지 않는 원리?
    • CSS는 태그 안에 있어야 한다. 왜냐하면 스타일 규칙이 있어야 랜더링을 할 수 있기 때문에 빠르게 알기 위해서이다.
    • 태그 안에 랑
    • requestAnimationFrame 함수
      • JS를 통해 일어나는 애니메이션 정보를 브라우저에 매 프레임마다 미리 알려줌
      • JS애니메이션이 프레임의 시작 시 실행되도록 보장!
      • requestAnimationFrame을 쓰면, 위와 같은 지연 및 블로킹 현상이 생기지 않아, 부드러운 애니메이션을 제공할 수 있다.

  • var let const
  • var를 안쓰는 이유?
  • 함수를 선언하는 방법은 어떤 것이 왜 다른지? 호이스팅? TDZ

  • settimeout, setinterval (명확히 시간이 준수되지는 않음..)
    • 비동기적인 코드를 작성해야 자바스크립트 엔진이 비동기적으로 실행이 되는 건지 아니면 자바스크립트 자체가 싱글 스레드 환경이라 동기적으로 동작하는데, 자바스크립트 엔진으로 비동기적으로 동작하게 할 수 있는건지?
    • ES의 최신문법을 Babel로 처리했을 때 비동기적으로 동작하게 하는 건 문제가 없는건가?
    • 과거에는 주로 setInterval, setTimeOut 등을 이용해서 간격을 정해놓고 연속으로 특정 이미지를 없앴다가 만들었다가를 빠르게 해서(과거 영화를 보여주던 원리와 같이 정적 이미지를 빠르게 넘기면서 보여주면 움직이는 효과가 나는 것처럼) 구현을 했었다. 그러나, 이 방법은 이벤트 루프(동기)에 의해 delay가 발생할 수 있고(간격이 빨라지고, 로직이 복잡해지면) 이에 따라 유저들이 해당 애니메이션을 부드럽지 않다고 느낄 가능성이 높아진다. 그래서 canvas 혹은 좀 더 부드러운 애니메이션을 위해서 HTML5 에서 등장한 것이 'requestAnimationFrame' 이다.
  • 60프레임 단위
    • 사람은 1초에 60개의 프레임을 볼 수 있다고 한다. 그 이상의 프레임을 더 찍어내더라도 사람이 느끼기엔 거의 차이가 없다는 말이다. 그래서 자바스크립트로 애니메이션을 구현할때도 1초에 60프레임정도를 찍어내면 된다. 그 말은, 1프레임을 찍어내는데 
      16.6ms(1000ms / 60frame)
      를 넘겨서는 안된다는 말이다
  • 이벤트 루프
  • requestAnimationFrame

  • 라이브러리, 프레임워크??
  • 리액트가 왜 뜨게 되었는지?
    • React의 Virtual DOM, Angular Change Detector는 왜 필요한가?

      일반적으로 DOM에 접근하여 여러번의 속성 변화, 여러번의 스타일 변화를 수행하면 그에 따라 여러번의 Reflow, Repaint가 발생하게 됩니다. 하지만 Virtual DOM은 이렇게 변화가 일어나 Reflow, Repaint가 필요한 것들을 한번에 묶어서 DOM에 전달하게 됩니다. 따라서 처리되는 Reflow, Repaint의 규모가 커질 수는 있지만 한번만 연산을 수행하게 됩니다. 이를 통해 여러번 Reflow, Repaint를 수행하여 연산이 반복적으로 일어나는 부분이 줄어들어 성능이 개선됩니다.

      물론 프레임워크 없이 순수한 Javascript로 똑같은 알고리즘을 구현할 수 있겠지만 실제로 구현하기에는 매우 어렵기 때문에 React, Angular가 이를 대신해주어 인기를 얻었습니다.

  • LEMIX, NEXT
    • NEXT - 서버 사이드 렌더링 개념..알아보기
  • Node, V8 런타임환경
  • npm
    • package manager - 다양한 라이브러리를 관리해주는..

  • git
  • branch 전략
  • merge
  • git flow

현재 받은 질문을 브레인스토밍해서 생각나는대로 필터 없이 바로 끄적이고 있다. (그렇기 때문에 이상하게 적어놓은 문장도 너무 많다;; 이해해주시길 바란다;)

사실 떠올라서 적어놓은 질문 중에 여기 말고 다른 노션 페이지에도 적어놓은 게 많다.

내가 브레인스토밍해서 적어놓은 꼬리질문들에 대해서도 하나씩 답을 찾아나가고 있다.

x표시 해놓은 부분이 일단 내 나름대로 찾아보고 질문에 대한 답을 정리해놓은 부분이다.
(다른 시트에 저장해놨다. 여기에는 그냥 떠오르는 질문과 검색하다가 나온 자료 몇 문장이 전부다.)

일단 나머지 질문들도 같은 방식으로 진행해보려고 한다.

profile
데이터리터러시를 중요하게 생각하는 프론트엔드 개발자

0개의 댓글