많은 블로그에서 브라우저의 Task Queue에 대해 다루고 있는데 이에 대해 상반된 내용이 많아서, 저 나름대로 정리하기 위해 작성되었습니다. 잘못된 내용이 있을 수 있으니 피드백 부탁드립니다.

1. Task queue는 callback queue와 같은 개념이다?

• ** Callback queue는 Task queue 의 한 종류일 수 있음.**
• Task queue는 html standard에서 사용되는 정식 명칭임.
• Callback queue는, 아무리 찾아봐도 정식 명칭은 아님. html standard에도 그 개념을 찾을 수 없으며, callback queue에 대해 정리해놓은 블로그들을 찾아가 보면 결국, 이 영상과 이 글이 그 출처였음.
• 이 영상과 글은 javascript의 이벤트 루프에 대해 직관적으로 잘 설명되어 있어서 개념 잡기에 좋으나, 문제의 callback queue와 task queue를 혼용해서 사용하고 있으며, callback queue에 대한 어떤 reference도 제공해 주지 않음.
• html standard을 기반으로 callback queue를 분석해 본다면, callback queue는 사용자 이벤트와 같은 비동기 작업들의 task source에 대응되는 task queue의 한 종류 일 수 있으며, *실제로 있는지는 확실하지 않음. *
• 확실하지 않은 이유는 html standard 자체가 task source를 느슨하게 정의해 놓았기 때문에, 실제 구현은 각자 브라우저에서 서로 다른 명칭으로 구현 되어 있을 수 있기 때문임.
• 따라서, 결론적으로 callback queue는 브라우저가 가지는 여러 task queue 중 하나일 수 있으나, 확실히 있는 지 없는지는 V8 엔진이나 다른 엔진을 까보기 전에는 확신하지 못함. (구현체의 실제 내부 명칭이나 기능 또한 다를 수 있음)

2. Task queue에서 task는 javascript를 실행하여 처리한다?

• ** 반은 맞고 반은 틀림**

• Task는 기본적으로 event loop의 task queue에서 처리되는 일의 단위이며, task source로부터 생성됨

• Task의 종류에는

  • Script
  • Event
  • HTML parse
  • Callback
  • Resource (비동기로 요청되는 컨텐트들이 도착했을 때 처리할 일)
  • Reacting to DOM manipulation (javascript로 DOM을 조작할 경우, 실제 javascript 실행이 끝나고 DOM을 조작하는 task)

  등이 있음

  • 위에서 HTML parse, Resource, Reacting to DOM manipulation은 javascript로 동작하는 task들이 아님
  • *Callback이나 Event, Script를 처리할 때만 V8과 같은 엔진을 통해 javascript를 실행하는 것임 *
  • *이렇기 때문에 task queue나 event loop는 V8 엔진 내부에 있는 것이 아닌, 외부에 존재하며 필요할 때만 V8 엔진을 통해 작업을 함 *

3. Rendering의 우선순위가 일반적인 task보다 높다?

• ** 맞음.**
• 우선순위의 정도는** microtask = rendering > task 순서임 - 더 자세히는, 브라우저마다 다를 수 있음**
• 참고 : 이벤트 루프 동작 과정 - event loop proceeding model
  1. 먼저 task queue에서 runnable task를 하나만 꺼내 실행함
  2. 그 후 microtask queue가 전부 비워질 때까지 microtask를 모두 실행함
  3. 그 후 렌더링 할 게 있는지 확인하고(Rendering Opportunity) 있으면 렌더링을 함
  4. 다시 첫번째로 돌아가서 무한히 반복하며, 일할 게 없으면 휴면 상태에 들어감

4. Task queue는 실제 자료구조는 queue이다?

• 아님.
• 실제로는 Set으로 구현되어 있으며, 대기하고 있는 task 중 runnable task를 뽑아내기 위해 이러한 구조를 가짐

더 찾아볼 만한 레퍼런스

Which types of queues are in event loop? 이벤트 루프, 매크로태스크, 마이크로태스크, 렌더링

브라우저의 동작 원리를 공부하다가, 이벤트 루프와 v8 엔진의 관계에 대해 명확히 정리하기 위해 작성되었습니다.

이벤트 루프와 V8 Engine의 관계

• 이벤트 루프는 V8 엔진을 포함하는 관계임 (이벤트 루프 ⊃ V8 engine)
• 이벤트 루프는 task queue를 가지고 있으며, 만약 task가 javascript를 실행해야 하는 일이면 그 경우 V8과 같은 자바스크립트 엔진을 가져다 사용함

V8 엔진 내부에 있는 개념들

• 자바스크립트를 실행하는데 필요한 것들이 존재한다고 보면 됨
• javascript call stack
• Execution context
• Heap - Garbage Collection
• Memory allocation (for javascript objects)

V8 엔진 외부에 있는 개념들

• event loop
• task queue, 다른 이름으로는 macrotask queue
• microtask queue, 다른 이름으로는 PromiseJobs
• web APIs - setTimeout(), fetch(), DOM 조작 ... (전부 javascript 안에서 부를 수 있지만, 실제 실행은 V8 엔진 외부에서 다른 언어로 브라우저에서 실행됨. web APIs 는 단지 연결 통로라고 생각하면 됨)
• 추가 - setTimeout 같은 몇몇 api는 이제 [V8 자체에서 지원하기 시작하였음] (https://stackoverflow.com/questions/12335222/settimeout-and-v8) (2020년 12월 기준)

reference

v8 engine event loop의 html standard 이벤트 루프는 자바스크립트 엔진 내부에 있는 것이 아니다 Does V8 have an event loop?

이 글은 Max Koretskyi 가 리버스 엔지니어링으로 React의 Source Code를 보고, 렌더링 과정을 분석해 놓은 블로그를 참고하여 작성되었습니다. 원본 내용을 더 간소화시키고 제가 정리한 내용을 추가하여서 틀린 부분이 있을 수 있으므로, 피드백 환영합니다

이해를 돕기 위한 배경 지식

• 이 글은 v16.0 버전 이후의 내용들을 다룸
• 사용자가 만든 리액트 컴포넌트는 리액트 조화 과정 내에서 fiber에 대응됨 (component => react element => fiber)
• 리액트는 브라우저 런타임에서 이 fiber 들을 활용하여 virtual DOM을 만듬

리액트 조화 과정 세부 구성요소

Render Phase

• 변화된 사항을 감지하여 새로운 virtual DOM을 생성하는 과정
• 변경사항들이 반영된 alternate virtual DOM tree를 생성하며, diffing algorithm을 이용하여 변화된 사항을 빠르게 적용하기 위한 effects list를 생성함

  Commit Phase

• Render phase에서 생성된 alternate tree와 effects list 를 활용하여 real DOM에 반영하는 과정

  effects list

• Render phase에서 생성된 real DOM 변경사항들을 가지고 있는 list

렌더 과정 정리 GIF

Step by Step 조화 과정

초기 상태

• 처음 virtual DOM tree가 다음과 같이 구성되었다고 가정

외부 변화 사항이 일어남

• 앱 사용자의 입력에 의해 B component의 state의 변경 혹은 props의 변화가 일어남

변화 사항이 일어난 fiber에 대해 flag(dirty check) 진행

• B component에 대응되는 B Fiber에 dirty check 수행

Render phase 시작

• renderRoot 함수가 실행되어 root로부터 렌더가 필요한 Fiber인 B를 빠르게 탐색함

Render phase 진행

• 렌더가 필요한 Fiber부터 순차적으로 beginWork() 함수가 실행되며, 새로운 virtual DOM Fiber를 만드는 작업을 완료하면서 completeWork()을 호출함
• 처음 dirty가 생긴 B Fiber의 completeWork() 호출이 끝나면 commit phase로 넘어감
• 또한 Render phase에서 diffing algorithm을 이용하여 effect list를 만듬

Render phase - memoized component의 경우

• 메모된 경우, 사용자가 입력한 compare function을 바탕으로 비교하거나 자체적인 shallow compare를 수행하여 새로 Component를 부를지 말지를 판단함
• 비교 결과 True이면, 기존에 만들어놨던 Fiber를 다시 이용함 updateMemoComponent updateSimpleMemoComponent bailoutOnAlreadyFinishedWork
• 비교 결과 False이면, 새로 Component Function이나 Class를 호출하여 Fiber를 다시 만듬

Commit phase 시작

• effect list에 있는 변경 사항들을 real DOM에 반영함

Commit phase - 변경사항이 없는 fiber의 경우

• E Fiber의 경우, effect list에 추가되지 않음
• 다만, 변경 사항이 없다고 하더라도 current와 alternate에 있는 fiber는 다른 객체임

Commit phase - memoized component의 경우

• G Fiber는 current와 alternate가 같은 pointer를 공유하므로, 실제로는 같은 객체임

Commit phase 진행

• effect list에 있는 변경 사항들을 모두 진행함
• useEffect의 경우도 이때 실행됨 The useEffect hook: a brief clarification on its usage
• 참고: real DOM의 attribute를 변경하는 source code

렌더 완료

• 변경사항 반영이 끝나고 새로운 vitual DOM Tree를 current tree로 가지고 있음

추가 참고 사항

Fiber는 엄밀히 말하면 트리 구조가 아닌 linked list로 연결되어 있다

• Fiber node들은 child 및 sibling 포인터를 가지며, 이로 인해 linked list 형태로 연결되어 있음

Fiber는 비동기적인 call stack frame을 자체적으로 구현한 것이다

• 리액트는 virtual DOM tree traversal을 수행할 때 DFS 방식의 recursion 순서로 진행한다고 보여짐
• 다만, 브라우저의 built-in call stack을 그대로 이용하여 구현하면, 변경해야 할 node들이 너무 많을 경우에 멈추지 못하고 call stack이 빌 때까지 작업을 계속하게 되어 다른 작업이 지연될 수 있음
• 따라서, 리액트 팀은 call stack을 중간에 interrupt하여 순서를 조작할 수 있는 비동기적인 가상의 stack frame model을 만들었으며, 그것이 Fiber 임

  원문 : If you rely only on the [built-in] call stack, it will keep doing work until the stack is empty…Wouldn’t it be great if we could interrupt the call stack at will and manipulate stack frames manually? That’s the purpose of React Fiber. Fiber is re-implementation of the stack, specialized for React components. You can think of a single fiber as a virtual stack frame.

  Reference

  Inside Fiber: in-depth overview of the new reconciliation algorithm in React The how and why on React’s usage of linked list in Fiber to walk the component’s tree The useEffect hook: a brief clarification on its usage

피드백 환영합니다

One dispatch, one virtual DOM render

• (dispatch가 store의 상태 변경을 유발하였을 경우) 리덕스는 모든 dispatch에 대해 모든 subscriber를 업데이트함
• 상태를 각자 다른 reducer로 분리하는것과는 상관없음
• e.g. 만약 store의 A field가 바뀌어도, B field를 구독하고 있는 컴포넌트에게도 기본적으로 noti가 가해짐
• 하나의 리덕스 앱은 결과적으로 하나의 root reducer function만을 가지기 때문임

Redux app really only has one reducer function: the "root reducer" function that you will pass to createStore later on. That one root reducer function is responsible for handling all of the actions that are dispatched, and calculating what the entire new state result should be every time. source: https://redux.js.org/tutorials/fundamentals/part-3-state-actions-reducers#writing-reducers

• 또한, 여러 번의 dispatch가 실행될 경우 virtual dom render도 그 횟수만큼 실행
• 다만, dispatch 하였을 때 store를 구독하고 있는 컴포넌트가 하나도 없다면 virtual DOM render 또한 일어나지 않음

Connect, useSelector의 차이점

• 모든 컴포넌트에게 noti를 하는 것은 맞으나, 내부적으로 connect를 사용하여 props를 전달하였을 경우에는 shallow compare를 통해 그 값이 바뀌었을 때만 re-render를 유발함
• useSelector 훅을 사용하였을 경우에는 이전 값과 비교하지만, === operator로 reference 비교를 하기 때문에 주의해야 할 사항이 있음. 아래 참조

  useSelector로 object가 아닌 값을 return 하는 경우

  import React from 'react'
  import { useSelector } from 'react-redux'
  

export const CounterComponent = () => { const counter = useSelector(state => state.counter) return

* 이 경우에 counter는 number 값이며, state.counter의  값이 바뀌지 않았다고 하면 ```===``` operator로 비교했을 때 ```true``` 일 것이므로, 리렌더링 되지 않음.

#### useSelector로 object를 return 하는 경우
```js
import React from 'react'
import { useSelector } from 'react-redux'

export const CounterComponent = () => {
  const {counter} = useSelector(state => ({counter : state.counter}))
  return <div>{counter}</div>
}

• 이 경우에 useSelector의 인자로 들어간 함수가 반환하는 값은 항상 새로운 object이며, 이 경우 === operator로 비교했을 때 false 일 것이므로 state.counter가 변경되지 않았다고 할지라도 리렌더링을 유발함

One dispatch do not induce one UI render

• 최종적으로 여러번의 dispatch가 끝난 다음, state가 마지막 상태로 동기화가 되면 그때 batched_update를 통해 한꺼번에 fiber에 변화를 반영하여 UI 렌더가 일어남

dispatch 최적화에 대해

• 한 dispatch에 여러 액션이 동시에 수행되도록 batching 하기
• 다만, 간단한 CRUD 앱의 경우 굳이 이런 공수를 들여 최적화할 필요는 없음
• 실시간으로 많은 양의 데이터를 주고받는 앱의 경우에 필요함
• e.g. 코인 거래소(실시간 호가 렌더), 채팅앱(실시간 동시다발적 채팅)

reference

https://react-redux.js.org/next/api/hooks#performance idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability React batched update 그리고 react-redux dispatch & actual render relations

이 포스트는 순수하게 필자의 생각을 정리한 것이므로 잘못된 내용이 있을 수 있습니다. 피드백 환영합니다.

브라우저의 비동기 작업

• 브라우저의 비동기 작업은 내장되어있는 Asynchronous Web APIs를 통해 진행됨
• e.g. SPA를 가능하게 해 주는 XMLHttpRequest
• e.g. 원활한 animation이 가능하게 해 주는 requestAnimationFrame
• 비동기로 일어날 작업을 주로 콜백 함수를 통해 등록하도록 되어 있음

Promise 자체는 비동기가 아니다

• Promise 패턴이 생겨난 가장 중요한 원인은 '콜백 지옥'을 해결하기 위해서임
• 비동기 작업을 도와주는 synthetic sugar라고 볼 수 있음
• 따라서 Promise 객체 자체는 비동기 / 동기 동작을 나누는 기준이 되지 않음
• 다음과 같은 코드에서 A는 Promise 객체이지만 resolve 혹은 reject가 동기적으로 처리됨

function doSyncWork () {
    return !!Math.round(Math.random());
    // true, false를 랜덤으로 반환함
}

let A = new Promise((resolve, reject) => {
    let work = doSyncWork();
    if (work) resolve(work);
    else reject('invalid work');
})

console.log(A);
// 이미 fullfilled 혹은 reject 처리가 되어 있다 

• resolve나 reject를 다른 비동기 API의 콜백 내부 에 집어넣어야 비동기로 동작함
• e.g. resolve를 setTimeout 콜백 함수에 집어넣는 경우

예시: Axios에서 Promise를 어떻게 사용하고 있는가

• Axios는 XMLHttpRequest를 Promise 객체로 감싸서 사용자에게 제공하고 있음
• Axios 에 get / post 등 요청이 들어오면, 새로운 XMLHttpRequest 객체를 Promise 객체 내부에 생성함 => 관련 코드
• XMLHttpRequest 객체의 onreadystatechange 메서드 콜백 함수 안에 resolve 및 reject 등록 => 관련 코드

주의: then / catch 핸들러는 비동기로 동작한다

function doSyncWork () {
    return !!Math.round(Math.random());
    // true, false를 랜덤으로 반환함
}

let A = new Promise((resolve, reject) => {
    let work = doSyncWork();
    if (work) resolve(work);
    else reject('invalid work');
})

A.then(() => console.log('async')).catch(() => console.log('async'));
console.log(A);

결과 : 
Promise <Fullfilled> or <rejected>
'async'

// then과 catch는 먼저 작성되었음에도 불구하고, console.log(A) 가 먼저 실행되었다

• Promise의 Resolve와 Reject는 microtask queue에 담기기 때문에 콜 스택에 담긴 자바스크립트가 전부 실행되고 나서 바로 실행됨

왜 Microtask queue 에서 실행될까?

microtask 간 동일한 환경 보장

• microtask 에서는 좀 더 높은 우선순위를 가지는 일들이 실행됨
• e.g) Mutation Observer, Intersection Observer, Promise-(then/catch handler)
• 마우스 좌표 변경이나 통신에 의한 데이터 변경 없이 모든 마이크로태스크를 동일한 환경에서 처리할 수 있음

비동기의 더 빠른 처리

doReallyAsyncWork1() //프로미스를 리턴하는 비동기 api
  .then(result => syncWork1(result)) // 만약 SyncWork이 반환하는 것이 promise가 아니면,
  .then(result => syncWork2(result)) // then 안에서는 Promise.resolve()로 감싸서 
  .then(result => syncWork3(result)) // 강제로 promise resolve 처리를 해서 내보낸다. 
  .then(result => doReallyAsyncWork2()) 
  .catch(err => alert(err))

• 위와 같은 코드에서, 비동기 동작을 요구하는것은 오직 2번 뿐인데, then 핸들러를 수행할때마다 똑같이 task queue에 담아놓으면 불필요하게 작업이 밀려 실행될 수 있음
• Microtask queue에서 실행되면 task 보다 우선적으로 처리 가능하므로, syncWork1, syncWork2, syncWork3는 main thread가 microtask를 수행할 때 전부 실행되어, task queue에 있는 task보다 더 우선되어 처리됨
• 따라서 더 빠른 처리가 가능함

이 글은 ReactConf AU 에서 CSS-in-JS 에 대한 Max Stoiber의 강연을 참조하여 제 생각을 정리한 것입니다.

CSS-in-JS가 등장하게 된 배경

MVC 혹은 MV* 구조를 가진 프레임워크는 개발하기 피곤함

• 하나의 컴포넌트를 만드려면 model, view, controller 뿐만 아니라 CSS 또한 분할된 개념으로 나누어 구현해야 함
• 때문에 코드가 분산되어 가독성이 떨어지고 복잡하며, 많은 코딩이 필요함
• 아이러니하게, MVC가 나온 이유는 각 부분의 역할에 따라 코드를 분할하여 가독성과 효율을 높이고 디펜던시를 줄이기 위함이었지만, 반대로 시간이 지나면서 최근에는 하나의 개념(컴포넌트)을 만드는데 파일을 3개나 만들어야 한다는게 피곤해지는 원인이 됨. css까지 포함하면 4개임

  컴포넌트 기반 프레임워크의 등장

• React / Vue와 같은 프레임워크는 컴포넌트라는 개념 단위를 도입함
• 컴포넌트는 model, view, controller를 개념적으로 포함하고 있으며 가상 돔 렌더의 단위가 됨
  • model: component안의 state / props
  • view : jsx (실제 돔 객체를 그리는 것은 리액트에서 알아서 함)
  • controller: event handlers (callbacks) - 모델 정보를 변경
• 개념이 단일화되어 좀 더 직관적이고 단순하게 이해할 수 있음
• 하지만 여전히, CSS는 컴포넌트와 별개로 작성해야 하는 한계가 있으며 그 개념도 분할되어 있음

CSS-in-JS를 도입하면 컴포넌트와 CSS를 통합할 수 있음

• CSS-in-JS로 CSS마저 컴포넌트의 구성 요소로 종속시킬 수 있음

그래서, 이렇게 컴포넌트에 종속시키면 무엇이 좋은가?

1. 오직 해당 컴포넌트에만 영향을 준다

• 기존 CSS 혹은 SCSS 방식처럼 classname을 수동으로 지정하여 스타일링 하는 것이 아님
• 다른 컴포넌트에 영향을 주지 않기 때문에 생성, 수정, 삭제가 자유로움 (디펜던시가 없음)

2. CSS 유지 보수가 쉽다

• 만약 협업을 하면서 운이 나쁘게 classname이 겹치게 되면, 어디서 문제가 생겼을지 몰라 수십개의 스타일시트를 전부 뒤져야함
• 따라서 CSS 작업을 할 때, 규모가 커지면 커질수록 십중팔구는 그 안의 CSS를 고쳐서 어떤 고장이 날 지 몰라 그냥 밑에 덧붙이는 경우가 대다수임
• 이럴 경우 유지 보수가 안되기 딱 좋음
• 하지만 CSS-in-JS 방식은 CSS가 특정 컴포넌트에 종속되기 때문에 다른 부작용에 대한 부담 없이, 마음대로 수정이 가능함

3. 협업하기 쉽다

• 기존 CSS를 사용하여 협업할 경우, classname 충돌이나 cascade styling override에 따른 문제가 발생하기 매우 쉬움
• CSS-in-JS 방식은 이러한 문제가 없으므로 CSS를 잘 모르는 사람들과의 협업도 원활하게 해 줌

4. 성능이 빠르다

• 기존 방식들은 전체 페이지에 필요한 CSS를 처음부터 전부 로딩하여 style 태그를 생성함
• CSS-in-JS는 그때 그때 필요한 만큼만 style 태그를 최소한으로 생성함

5. 향상된 동적 스타일링

• CSS-in-JS는 컴포넌트 라이프사이클에 맞추어 CSS를 변경할 수 있으므로, 좀 더 자유로운 동적 스타일링이 가능함
• e.g. 컴포넌트의 상태를 style에 적용할 수 있음 (props 전달)

CSS-in-JS 는 어떻게 동작하는가?

1. classname 동적 생성

• CSS-in-JS 사용자가 스타일에 classname을 사용하지 않더라도, 결국 브라우저는 webkit 엔진에서 스타일링을 수행할 때 classname을 기반으로 하고 있기 때문에 브라우저 런타임에서는 각 CSS 와 컴포넌트를 이어주는 classname이 필요함
• CSS-in-JS 에서는 각 컴포넌트를 hashing하여 동적인 classname을 만듬
• e.g. "sc-cMWNzn"
• 컴포넌트가 생성될 때 head tag에 style tag로 같이 생성되며, 사라질때도 같이 사라짐 (라이프사이클이 같음)
• styled-components의 경우, 같은 컴포넌트가 여러개 생성될 때는 하나의 css만 사용됨 => 최적화가 되어 있음

2. css parser

• 각 CSS-in-JS 엔진은 style html tag를 만드는 CSS parser를 내장하고 있음
• styled-components는 stylis라는 CSS preprocessor를 이용함
• material-ui의 경우도 비슷한 방식으로 동적 생성을 지원함

동작 원리 요약

reference

https://www.youtube.com/watch?v=ufPCITfUQnQ&t=261s

결론만 말하자면, 이벤트 위임을 통해서 이벤트 리스너의 개수를 줄이려 하더라도 의미 없고, 성능 향상도 없다.

성능 향상을 목적으로 하는 Native JS 에서의 이벤트 위임(Event Delegation)

리액트에서의 이벤트 위임

Reference

Event delegation in React

본 글은 2018년 GOTO conference에서 Russ Olsen이 발표한 'Functional Programming in 40 Minutes' 의 강연 내용을 제가 이해한 내용을 바탕으로 정리한 것입니다.

객체지향과 비교하여 강의가 진행되기 때문에, 객체지향에 대한 이해가 조금 있으면 이 강의를 듣는데 도움이 됩니다.

객체지향 프로그래밍의 한계점

=> 근본적으로, 시간에 따라 변하는 속성을 제대로 파악하지 못하는 지경이 되는 것이 문제같은데, 이걸 해결할 방법이 마땅치 않아 보인다.

대체제가 있을까?

=> 객체지향을 이루는 요소들 대신, 함수형 구성 요소인 순수 함수 / 불변성 자료 구조 / 사이드 이펙트 브릿지를 활용하면 더 좋은 프로그래밍이 가능할 수 있다.

함수형 구성 요소

1. 순수 함수

사이드 이펙트

순수 함수가 왜 중요한가?

=> 디펀덴시가 최소화됨

2. 불변성(Immutable) 자료 구조

** => 왜 그럴까? 불변하지 않으면 사이드 이펙트가 발생하는 것과 동일함. => 따라서 순수 함수를 사용하는 이점이 의미가 없어짐**

3. 사이드 이펙트 브릿지 - closure(클로져) 방식

예시: Atoms

function funcA() {
... 연산 후
return someValue
}

Atom(funcA()) // function 자체를 인자로 받아 다시 atom 안의 변수 값에 someValue를 다시 반영

예시: atom은 mutable variable를 그냥 하나를 두는 것과 무엇이 다른가?

=> 바닐라 자바스크립트에서는 이런 구조를 만들 수 있을까? 한번 시도해 봐야겠다. 그 후 업데이트 예정

예시: agents/actors

=> 이것도 바닐라 자바스크립트에서 만들 수 있을까? 해보고 업데이트 예정

함수형만이 갖는 압도적 장점 => 여러 쓰레드를 활용할 경우

함수형 프로그래밍을 시도해보자

출처 : https://www.youtube.com/watch?v=0if71HOyVjY