맥에서 웹을 개발하다보면 단점 아닌 단점이 하나 있는데, 바로 웹 화면이 다른 플랫폼에서 스크롤로 도배되어 있다는 것이다. 맥의 경우에는 커서가 플랫폼 화면에 올라오는 순간에 스크롤 막대가 올라온다.

![naver-mac](./images/naver-mac.png)

> 맥은 스크롤바가 보이지 않는다.

![naver-window](./images/naver-window.png)

> 그러나 윈도우는 기본적으로 스크롤바를 깔고 간다.

같은 사이트라 할지라도, 맥은 기본적으로 애플리케이션 영역에 커서가 올라오지 않는 이상 스크롤바를 보여주지 않는다. 이는 다음과 같은 속성 때문이다.

![mac](./images/mac-scroll-preference.png)

> 스크롤 막대보기: 마우스 또는 트랙패드에 따라 자동으로 설정이 기본값으로 되어 있다.

종종 이러한 특징 때문에 맥에 대한 비난 내지는 혼선이 빚어지는데, 사실 범인은 개발자다.

**결론부터 이야기 하자면 `overflow:scroll`는 항상 스크롤 막대를 표시한다.** 그러나 대부분의 개발자들은 맥의 기본동작 처럼, 필요한 경우에만 스크롤 바를 표시하고 싶을 것이다. 이를 위해서는 `overflow: auto`를 활용하여 브라우저 스스로가 스크롤 바가 필요한지 여부를 자동으로 결정하도록 해야 한다.

이러한 문제가 발생하고 있는 곳이 링크드인 이다.

![linkedin-window-scroll](./images/linkedin-window-scrollbar.png)

링크드인에서 포스트를 올릴 때, 스크롤이 필요하지 않은 상황임에도 윈도우에서 비활성화된 스크롤바가 보이는 것을 볼 수 있다. 사진까지 올리면 이제 스크롤바가 불필요하게 중첩까지 된다.

![linkedin-window-duplicated-scrollbar.png](./images/linkedin-window-duplicated-scrollbar.png)

문제는 `overflow-y: scroll`이다. 해당 옵션을 수정하면 컨텐츠가 넘쳐날 때만 스크롤 바가 뜬다.

![linkedin-post-window-scroll-auto](./images/linkedin-post-window-scroll-auto.png)

![linkedin-post-window-scroll](./images/linkedin-post-window-scroll.png)

> 스크롤바를 의도한 걸 수도 있다. 하지만 대부분은 버그입니다.

https://developer.mozilla.org/ko/docs/Web/CSS/overflow

> `scroll`:콘텐츠를 안쪽 여백 상자에 맞추기 위해 잘라냅니다. 브라우저는 콘텐츠를 실제로 잘라냈는지 여부를 따지지 않고 항상 스크롤바를 노출하므로 내용의 변화에 따라 스크롤바가 생기거나 사라지지 않습니다. 프린터는 여전히 넘친 콘텐츠를 출력할 수도 있습니다.

> `auto`: 사용자 에이전트가 결정합니다. 콘텐츠가 안쪽 여백 상자에 들어간다면 visible과 동일하게 보이나, 새로운 블록 서식 문맥을 생성합니다. 데스크톱 브라우저의 경우 콘텐츠가 넘칠 때 스크롤바를 노출합니다.

이와 별개로 가로 스크롤바가 생기는 문제가 간혹 있는데, 이는 `body`나 `html`에 `100vw`를 설정했을 때다. 이 또한 맥에서는 정상적으로 작동하지만, 다른 플랫폼에서는 그렇지 못하다.

![window-100vw](./images/window-100vw.png)

> 윈도우 크롬에서 `body`에 `100vw`를 적용

![mac-100vw](./images/mac-100vw.png)

> 맥 크롬에서 `body`에 `100vw`를 적용

그 이유는 아마도 다른플랫폼에서는 `100vw`에 스크롤바의 너비까지 포함하기 때문일 것이다. 이 경우 `100%`를 적용하면 해결이 된다.


맨날 맥만 봐서 이런 줄도 몰랐다 반성합니다

overflow: auto vs overflow: scroll 왜 윈도우에서만 쓸모없는 스크롤바가 노출될까

[이 전 블로그 포스팅](https://yceffort.kr/2021/01/brotli-better-html-compression)을 통해서 brotli가 무엇인지, 왜 좋은지, 왜 써야 하는지에 대해서 알아봤다. 그러나 한 가지 더 궁금한 것이 있다. 과연 비단 IE 에서 지원하지 않는다는 이유만으로 쓰지 않는 것일까? 시스템 엔지니어들이 게을러서 brotli 지원을 안해주는 것일까?

Gzip은 웹 압축에 있어서 일종의 디 팩토 같이 자리잡고 있다. 대충 모든 웹사이트의 80% 정도가 gzip으로 서빙되고 있는 것으로 알려져 있다. [참고](https://almanac.httparchive.org/en/2019/compression) 근데 압축이 안되있는 사이트가 60% 쯤 정도 된다. (허허)

아무튼 지간에, Gzip도 충분히 효과적인 압축 알고리즘이지만, brotli가 gzip보다 더 크게 압축해 주는 알고리즘으로 등장했다.

![gzip-vs-brotli](https://csswizardry.com/wp-content/uploads/2020/04/react-dom-brotli.png)

그리고 이전에 말했듯이, IE에서는 brotli를 지원하지ㄷ 않지만, 현재 사이트의 93%가 IE외의 환경에서 서비스 되므로 대부분의 사용자에게 brotli를 이용하여 서비스 할 수 있다. 6%는 무시하라는 말처럼 들릴 수도 있지만(?) brotli를 받아줄 수 없는 브라우저의 경우 gzip으로 fallback 되게 할 수 있다. 이는 나중에 다룬다.

그런데 왜, 많은 사이트들이 brotli를 사용하지 않는 것일까? brotli로 전환하는 것은 얼마나 중요한 것일까?

## 작다는 것이 반드시 더 빠르다는 것은 아니다.

물론, 일반적으로는 작은 파일이 더 빠르게 도착하는 것이 사실이다. 그렇다고 파일 크기를 20% 줄였다고 20% 더 빠르게 도착하는 것은 아니다. 다시 말해 파일 크기는 웹 성능을 측정하는 한가지 측면일 뿐, 이 외에도 리소스 대기시간, 패킷손실과 같은 다른 많은 요소와 상수가 웹 성능에 영향을 미친다. 크기를 절약하는 것은 데이터를 더 빠르게 도착하게 하는 것에 도움이 되지만, latency 에 제한이 있는 경우에는 데이터 청크가 도달하는 속도에 영향을 미치지 않는다.

## TCP, Packet, Round trip

먼저 tcp에 대해 알아보자. 서버에서 파일을 받을 때는 한번에 전체 파일을 가져오지 않는다. HTTP가 위치한 TCP는 파일을 세그먼트 또는 패킷으로 나눈다. 이러한 패킷은 순서대로 클라이언트에 전송된다. 패킷은 클라이언트가 모든 패킷을 가질 때 까지, 다음 패킷을 전송하기 전에 각 패킷을 확인하고 전송하며, 클라이언트가 이러한 패킷을 조립하여 하나의 파일로 조립하게 된다. 이러한 일련의 패킷은 라운드 트립 방식으로 전송된다.

각각의 새로운 TCP 연결은 현재 사용 가능한 대역폭이 무엇인지, 연결을 얼마나 신뢰할 수 있는지를 알 수 있는 방법이 없다. (예: 패킷 손실 등) 만약 서버가 한 연결당 1메가 비트 짜리 연결을 통애 메가바이트급 전송을 시도한다면, 서버 연결 요청이 쇄도하여 혼잡이 발생하게 될 것이다. 만약 1메가 바이트의 사용가능한 연결을 바탕으로 1메가 비트의 데이터를 전송하려고 한다면, 용량이 낭비되고 말 것이다.

이를 해결하기 위해 [TCP는 slow start를 사용한다.](https://ko.wikipedia.org/wiki/%ED%98%BC%EC%9E%A1_%EC%A0%9C%EC%96%B4) 각각의 새로운 TCP연결은 첫번째 왕복에서 데이터 패킷 10개만 사용하도록 제한된다. (약 14kb) 10개가 성공적으로 도착한다면, 그 다음에는 20개의 패킷을, 그다음에는 40, 80, 160 으로 기하급수적으로 증가하는데 이 증가는 다음 수준에 다다를 때 까지 발생한다.

1. 패킷손실이 발생. 이 지점에서 서버는 마지막 패킷 수를 절반으로 줄이고 다시 시도
2. 대역폭 최대에 다달아서 최대 용량을 사용가능한 경우

이러한 전략은 웹 애플리케이션이 만드는 모든 새로운 TCP연결에 활용된다.

다시 브라우저로 돌아와서, 새 TCP 연결의 초기 대역폭 용량은 14kb다. 리액트로 예를 들어서, 아래의 표를 보자.

| Round Trip | TCP Capacity (kb) | Cumulative Transfer (kb) | React DOM               |
| ---------- | ----------------- | ------------------------ | ----------------------- |
| 1          | 14                | 14                       |                         |
| 2          | 28                | 42                       | Gzip(37kb) Brotli(33kb) |
| 3          | 56                | 98                       |                         |
| 4          | 112               | 210                      | Uncompressed (119kb)    |
| 5          | 224               | 434                      |                         |

(둘다 최대 치로 압축)

**압축은 brotli가 4kb나 더 되었지만, TCP 작동 원리에 따라서 모두 두 번째 왕복에 다운로드가 완료 되었다. 따라서, 모든 왕복시간이 거의 균일하다면, Gzip이나 brotli나 모두 전송시간에 차이가 없다는 결론이 나오게 된다.**

따라서 요점은 파일 크기가 아니라, TCP, 즉 패킷 및 왕복에 관한 것이다. 파일을 더 작게 만드는 것이 문제가 아니고, 파일을 의미있게 작게 만들어서 더 낮은 왕복 버킷에 집어 넣어야 한다. 결과적으로, brotli가 gzip보다 더욱 효과적이라면 파일을 왕복 임계값 아래로 (위의 예제에서는 14kb급으로), 더욱 공격적으로 압축을 할 수 있어야 한다.

이 규칙은 또한 새로운 TCP 연결에만 적용되며, primed TCP 연결로 가져온 파일은 영향을 받지 않는다. 이는 두가지 중요한 점을 제시한다.

1. 정적자산을 자체 호스팅 하는것이 중요하다. 이렇게 하면 이미 워밍업되어 있는 (새로 연결되어 있는) TCP에 연결 할 수 있으므로, 시작속도가 느려지는 것을 방지할 수 있다.
2. 기하 급수적으로 패킷이 커지면 얼마나 거대한 대역폭에 빠르게 도달할 수 있다. 연결을 더 많이 쓰고 재사용할 수록 용량이 빠르게 늘어난다.

| Round Trip | TCP Capacity (kb) | Cumulative Transfer (kb) |
| ---------- | ----------------- | ------------------------ |
| 1          | 14                | 14                       |
| 2          | 28                | 42                       |
| 3          | 56                | 98                       |
| 4          | 112               | 210                      |
| 5          | 224               | 434                      |
| 6          | 448               | 882                      |
| 7          | 896               | 1778                     |
| 8          | 1792              | 3570                     |
| 9          | 3584              | 7154                     |
| 10         | 7168              | 14322                    |
| ...        | ...               | ...                      |
| 20         | 7340032           | 14680050                 |

10 회 왕복정도면, TCP는 7168kb이고, 14322kb를 전송했다. 이는 일반적인 웹 브라우징에 적합하다. 여기서 말하는 `일반적인`이라는 것은 대역폭 한계에 도달하기 전에 전체 웹페이지와 모든 하위 리소스를 로드 하는 것이다. 따라서, 1gbps 급 속도는 대부분 사용하지 않기 때문에 일상적인 브라우징이 더 빨라졌던가 하는 것은 느끼지 못하게 된다.

## 실제 세계에서의 실험

brotli로 제공되는 사이트에 brotli 사용을 중지하면 된다. https://www.webpagetest.org/ 에서 `content-encoding`에 `gzip`을 명시해주면 된다.

- 압축을 완전히 비활성화: `accept-encoding: 랜덤문자열`
- brotli비활성화 및 gzip: `accept-encoding: gzip`
- brotli: 비워 둔다.

결과: https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit#gid=0

- gzip 크기 감소 vs 비압축: 73% 감소
- gzip fcp vs 비 압축: 23 % 감소
- brotli 크기 감소 vs gzip: 5%
- brotli fcp vs 5zip: 3%

gzip은 비 압축 대비 약 72% 정도의 크기 감소를 이뤄 냈고, 이에 더해 brotli는 gzip 대비 5.7%를 더 감소 시켰다.

## 결론

gzip에 비해 brotli가 갖는 이점은 미미하다.

brotli를 활성화 하는 것이 CDN 관리자 메뉴의 버튼 하나를 누르는 것 만큼 간단하다면 지금 바로 실행하는 것이 좋다. 최소한의 개선이라도 없는 것보단 낫고, fallback 제공도 잘 되어 있다.

가능한 경우 정적 자산의 경우 가능한 가장 큰 압축 수준을 사용하며, 동적인 요소에 대해서는 중간 정도의 압축을 해주는 것이 좋다. 만약 nginx 를 사용중이라면, 현재 압축수준이 1로 (기본값으로) 되어 있는지 확인해보는 것이 좋다.

brotli를 구현하기 위해 너무 애쓸 필요는 없다. 압축할 수 있는 모든 항목에 대해 gzip이 제공되고 있다면, 그것만으로도 충분할 수 있다.

출처: https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/#smaller-doesnt-necessarily-mean-faster


항상 왜 그럴까를 고민해 봐야 하는 것 같다

그런데 왜 brotli를 사용하지 않는 것일까? 🤔

<a href="https://yceffort.kr/2021/01/brotli-better-html-compression">이 전 블로그 포스팅</a>을 통해서 brotli가 무엇인지, 왜 좋은지, 왜 써야 하는지에 대해서 알아봤다. 그러나 한 가지 더 궁금한 것이 있다. 과연 비단 IE 에서 지원하지 않는다는 이유만으로 쓰지 않는 것일까? 시스템 엔지니어들이 게을러서 brotli 지원을 안해주는 것일까?
Gzip은 웹 압축에 있어서 일종의 디 팩토 같이 자리잡고 있다. 대충 모든 웹사이트의 80% 정도가 gzip으로 서빙되고 있는 것으로 알려져 있다. <a href="https://almanac.httparchive.org/en/2019/compression">참고</a> 근데 압축이 안되있는 사이트가 60% 쯤 정도 된다. (허허)
아무튼 지간에, Gzip도 충분히 효과적인 압축 알고리즘이지만, brotli가 gzip보다 더 크게 압축해 주는 알고리즘으로 등장했다.
<img src="https://csswizardry.com/wp-content/uploads/2020/04/react-dom-brotli.png" alt="gzip-vs-brotli">
그리고 이전에 말했듯이, IE에서는 brotli를 지원하지ㄷ 않지만, 현재 사이트의 93%가 IE외의 환경에서 서비스 되므로 대부분의 사용자에게 brotli를 이용하여 서비스 할 수 있다. 6%는 무시하라는 말처럼 들릴 수도 있지만(?) brotli를 받아줄 수 없는 브라우저의 경우 gzip으로 fallback 되게 할 수 있다. 이는 나중에 다룬다.
그런데 왜, 많은 사이트들이 brotli를 사용하지 않는 것일까? brotli로 전환하는 것은 얼마나 중요한 것일까?
<h2 id="작다는-것이-반드시-더-빠르다는-것은-아니다">작다는 것이 반드시 더 빠르다는 것은 아니다.</h2>
물론, 일반적으로는 작은 파일이 더 빠르게 도착하는 것이 사실이다. 그렇다고 파일 크기를 20% 줄였다고 20% 더 빠르게 도착하는 것은 아니다. 다시 말해 파일 크기는 웹 성능을 측정하는 한가지 측면일 뿐, 이 외에도 리소스 대기시간, 패킷손실과 같은 다른 많은 요소와 상수가 웹 성능에 영향을 미친다. 크기를 절약하는 것은 데이터를 더 빠르게 도착하게 하는 것에 도움이 되지만, latency 에 제한이 있는 경우에는 데이터 청크가 도달하는 속도에 영향을 미치지 않는다.
<h2 id="tcp-packet-round-trip">TCP, Packet, Round trip</h2>
먼저 tcp에 대해 알아보자. 서버에서 파일을 받을 때는 한번에 전체 파일을 가져오지 않는다. HTTP가 위치한 TCP는 파일을 세그먼트 또는 패킷으로 나눈다. 이러한 패킷은 순서대로 클라이언트에 전송된다. 패킷은 클라이언트가 모든 패킷을 가질 때 까지, 다음 패킷을 전송하기 전에 각 패킷을 확인하고 전송하며, 클라이언트가 이러한 패킷을 조립하여 하나의 파일로 조립하게 된다. 이러한 일련의 패킷은 라운드 트립 방식으로 전송된다.
각각의 새로운 TCP 연결은 현재 사용 가능한 대역폭이 무엇인지, 연결을 얼마나 신뢰할 수 있는지를 알 수 있는 방법이 없다. (예: 패킷 손실 등) 만약 서버가 한 연결당 1메가 비트 짜리 연결을 통애 메가바이트급 전송을 시도한다면, 서버 연결 요청이 쇄도하여 혼잡이 발생하게 될 것이다. 만약 1메가 바이트의 사용가능한 연결을 바탕으로 1메가 비트의 데이터를 전송하려고 한다면, 용량이 낭비되고 말 것이다.
이를 해결하기 위해 <a href="https://ko.wikipedia.org/wiki/%ED%98%BC%EC%9E%A1_%EC%A0%9C%EC%96%B4">TCP는 slow start를 사용한다.</a> 각각의 새로운 TCP연결은 첫번째 왕복에서 데이터 패킷 10개만 사용하도록 제한된다. (약 14kb) 10개가 성공적으로 도착한다면, 그 다음에는 20개의 패킷을, 그다음에는 40, 80, 160 으로 기하급수적으로 증가하는데 이 증가는 다음 수준에 다다를 때 까지 발생한다.
<ol>
<li>패킷손실이 발생. 이 지점에서 서버는 마지막 패킷 수를 절반으로 줄이고 다시 시도</li>
<li>대역폭 최대에 다달아서 최대 용량을 사용가능한 경우</li>
</ol>
이러한 전략은 웹 애플리케이션이 만드는 모든 새로운 TCP연결에 활용된다.
다시 브라우저로 돌아와서, 새 TCP 연결의 초기 대역폭 용량은 14kb다. 리액트로 예를 들어서, 아래의 표를 보자.
<table>
<thead>
<tr>
<th>Round Trip</th>
<th>TCP Capacity (kb)</th>
<th>Cumulative Transfer (kb)</th>
<th>React DOM</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>14</td>
<td>14</td>
<td></td>
</tr>
<tr>
<td>2</td>
<td>28</td>
<td>42</td>
<td>Gzip(37kb) Brotli(33kb)</td>
</tr>
<tr>
<td>3</td>
<td>56</td>
<td>98</td>
<td></td>
</tr>
<tr>
<td>4</td>
<td>112</td>
<td>210</td>
<td>Uncompressed (119kb)</td>
</tr>
<tr>
<td>5</td>
<td>224</td>
<td>434</td>
<td></td>
</tr>
</tbody>
</table>
(둘다 최대 치로 압축)
압축은 brotli가 4kb나 더 되었지만, TCP 작동 원리에 따라서 모두 두 번째 왕복에 다운로드가 완료 되었다. 따라서, 모든 왕복시간이 거의 균일하다면, Gzip이나 brotli나 모두 전송시간에 차이가 없다는 결론이 나오게 된다.
따라서 요점은 파일 크기가 아니라, TCP, 즉 패킷 및 왕복에 관한 것이다. 파일을 더 작게 만드는 것이 문제가 아니고, 파일을 의미있게 작게 만들어서 더 낮은 왕복 버킷에 집어 넣어야 한다. 결과적으로, brotli가 gzip보다 더욱 효과적이라면 파일을 왕복 임계값 아래로 (위의 예제에서는 14kb급으로), 더욱 공격적으로 압축을 할 수 있어야 한다.
이 규칙은 또한 새로운 TCP 연결에만 적용되며, primed TCP 연결로 가져온 파일은 영향을 받지 않는다. 이는 두가지 중요한 점을 제시한다.
<ol>
<li>정적자산을 자체 호스팅 하는것이 중요하다. 이렇게 하면 이미 워밍업되어 있는 (새로 연결되어 있는) TCP에 연결 할 수 있으므로, 시작속도가 느려지는 것을 방지할 수 있다.</li>
<li>기하 급수적으로 패킷이 커지면 얼마나 거대한 대역폭에 빠르게 도달할 수 있다. 연결을 더 많이 쓰고 재사용할 수록 용량이 빠르게 늘어난다.</li>
</ol>
<table>
<thead>
<tr>
<th>Round Trip</th>
<th>TCP Capacity (kb)</th>
<th>Cumulative Transfer (kb)</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>14</td>
<td>14</td>
</tr>
<tr>
<td>2</td>
<td>28</td>
<td>42</td>
</tr>
<tr>
<td>3</td>
<td>56</td>
<td>98</td>
</tr>
<tr>
<td>4</td>
<td>112</td>
<td>210</td>
</tr>
<tr>
<td>5</td>
<td>224</td>
<td>434</td>
</tr>
<tr>
<td>6</td>
<td>448</td>
<td>882</td>
</tr>
<tr>
<td>7</td>
<td>896</td>
<td>1778</td>
</tr>
<tr>
<td>8</td>
<td>1792</td>
<td>3570</td>
</tr>
<tr>
<td>9</td>
<td>3584</td>
<td>7154</td>
</tr>
<tr>
<td>10</td>
<td>7168</td>
<td>14322</td>
</tr>
<tr>
<td>...</td>
<td>...</td>
<td>...</td>
</tr>
<tr>
<td>20</td>
<td>7340032</td>
<td>14680050</td>
</tr>
</tbody>
</table>
10 회 왕복정도면, TCP는 7168kb이고, 14322kb를 전송했다. 이는 일반적인 웹 브라우징에 적합하다. 여기서 말하는 <code>일반적인</code>이라는 것은 대역폭 한계에 도달하기 전에 전체 웹페이지와 모든 하위 리소스를 로드 하는 것이다. 따라서, 1gbps 급 속도는 대부분 사용하지 않기 때문에 일상적인 브라우징이 더 빨라졌던가 하는 것은 느끼지 못하게 된다.
<h2 id="실제-세계에서의-실험">실제 세계에서의 실험</h2>
brotli로 제공되는 사이트에 brotli 사용을 중지하면 된다. <a href="https://www.webpagetest.org/">https://www.webpagetest.org/</a> 에서 <code>content-encoding</code>에 <code>gzip</code>을 명시해주면 된다.
<ul>
<li>압축을 완전히 비활성화: <code>accept-encoding: 랜덤문자열</code></li>
<li>brotli비활성화 및 gzip: <code>accept-encoding: gzip</code></li>
<li>brotli: 비워 둔다.</li>
</ul>
결과: <a href="https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit#gid=0">https://docs.google.com/spreadsheets/d/18A_dP1DuavmMjmFnHXf4gdw6ThTne5e6UyzUUgxKI5s/edit#gid=0</a>
<ul>
<li>gzip 크기 감소 vs 비압축: 73% 감소</li>
<li>gzip fcp vs 비 압축: 23 % 감소</li>
<li>brotli 크기 감소 vs gzip: 5%</li>
<li>brotli fcp vs 5zip: 3%</li>
</ul>
gzip은 비 압축 대비 약 72% 정도의 크기 감소를 이뤄 냈고, 이에 더해 brotli는 gzip 대비 5.7%를 더 감소 시켰다.
<h2 id="결론">결론</h2>
gzip에 비해 brotli가 갖는 이점은 미미하다.
brotli를 활성화 하는 것이 CDN 관리자 메뉴의 버튼 하나를 누르는 것 만큼 간단하다면 지금 바로 실행하는 것이 좋다. 최소한의 개선이라도 없는 것보단 낫고, fallback 제공도 잘 되어 있다.
가능한 경우 정적 자산의 경우 가능한 가장 큰 압축 수준을 사용하며, 동적인 요소에 대해서는 중간 정도의 압축을 해주는 것이 좋다. 만약 nginx 를 사용중이라면, 현재 압축수준이 1로 (기본값으로) 되어 있는지 확인해보는 것이 좋다.
brotli를 구현하기 위해 너무 애쓸 필요는 없다. 압축할 수 있는 모든 항목에 대해 gzip이 제공되고 있다면, 그것만으로도 충분할 수 있다.
출처: <a href="https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/#smaller-doesnt-necessarily-mean-faster">https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/#smaller-doesnt-necessarily-mean-faster</a>

디자인 패턴에는 세가지 유형이 있다.

- Creational: 객체 인스턴스 생성
- Structural: 객체 설계 방식
- Behavioural: 객체가 상호 작용하는 방식

## Singleton

클래스의 단일 인스턴스만을 원할 때 이 패턴을 사용한다. 즉, 여러개의 인스턴스를 생성하는 것이 아니라 하나만 생성하는 것이다. 인스턴스가 없다면 새 인스턴스를 생성한다. 인스턴스가 있는 경우에는, 해당 인스턴스를 사용한다.

```javascript
class DatabaseConnection {
  constructor() {
    this.databaseConnection = 'dummytext'
  }

  getNewDBConnection() {
    return this.databaseConnection
  }
}

class Singleton {
  constructor() {
    throw new Error('Use the getInstance() method on the Singleton object!')
  }

  getInstance() {
    if (!Singleton.instance) {
      Singleton.instance = new DatabaseConnection()
    }

    return Singleton.instance
  }
}

module.exports = Singleton
```

위에서 보이는 것 처럼, 싱클턴을 구축할 수 있는 많은 예제가 있다. 이 외에 이 설계 패턴을 구현하는 더 짧은 방법이 있다.

```javascript
class DatabaseConnection {
  constructor() {
    this.databaseConnection = 'dummytext'
  }

  getNewDBConnection() {
    return this.databaseConnection
  }
}

module.exports = new DatabaseConnection()
```

이것이 작동할 수 있는 이유는 module caching system 이다. [module caching system이란, 모듈이 처음 로딩 된 이후에 캐싱이 되는 것을 의미한다.](https://nodejs.org/api/modules.html#modules_caching) 즉, 위의 예제에서는, 새롭게 exported된 인스턴스는 캐싱이 되며, 이것이 재 사용될 때마다 이 캐쉬댄 내용을 불러온다는 뜻이다.

따라서,Nodejs에서 싱글턴을 구현하는 방법은 위 처럼 두가지로 볼 수 있다.

### 요약

- 싱클턴 방식은 단 하나의 클래스 인스턴스가 필요할 때 유용하다.
- Nodejs에서는, module caching system을 활용해서 export한 모듈을 바로 쓸 수 있다.

## 팩토리

팩토리 디자인 패턴은, 객체를 생성하는데 사용되는 인터페이스 또는 추상 클래스를 정의 하는 것이다. 이렇게 생성된 인터페이스 및 추상클래스를 사용하여 다른 객체를 초기화 한다. 아래의 예를 살펴보자.

```javascript
import Motorvehicle from './Motorvehicle'
import Aircraft from './Aircraf'
import Railvehicle from './Railvehicle'

const VehicleFactory = (type, make, model, year) => {
  if (type === car) {
    return new Motorvehicle('car', make, model, year)
  } else if (type === airplane) {
    return new Aircraft('airplane', make, model, year)
  } else if (type === helicopter) {
    return new Aircraft('helicopter', make, model, year)
  } else {
    return new Railvehicle('train', make, model, year)
  }
}

module.exports = VehicleFactory
```

이렇게 각 클래스 인스턴스를 별개로 만드는 대신에, `VehicleFactory`를 활용해서 타입을 명시하는 방법을 택할 수 있다. 위 예제를 활용해서, `car` 인스턴스를 만들려면 아래처럼 실행하면 된다.

```javascript
// 첫번째 매개변수에서 타입을 지정하고, 나머지는 그대로 변수를 넘긴다.
const audiAllRoad = VehicleFactory('car', 'Audi', 'A6 Allroad', '2020')
```

팩토리 디자인 패턴을 사용하면 객체의 구조가 객체 그 자체 사이를 디커플링 시킬 수 있다는 장점이 있다. 기존 코드를 손상시키지 않더라도 새 객체를 응용프로그램에 사용할 수 있다. 마지막으로, 인스턴스 생성과 관련된 모든 코드가 한 곳에 있으므로 코드를 더 잘 꾸밀 수 있다.

### 요약

- 팩토리 디자인 패턴은 객체 생성을 위한 인터페이스 및 추상 클래스를 제공한다.
- 동일한 인터페이스 및 추상 클래스를 사용하여 다른 객체를 만들 수 있다.
- 코드의 구조를 개선하고 유지관리가 더 쉬워 진다.

## 빌더

빌더 디자인 패턴 또한 마찬가지로 객체 구조와 객체를 분리할 수 있다. 따라서 복잡한 객체를 생성하는 코드를 단순화 한다. 단순한 객체를 만들 때는 과한 기능일 수 있지만, 복잡한 객체를 만들 때는 단순화 하는데 도움을 준다.

```javascript
class Car {
  constructor(make, model, year, isForSale = true, isInStock = false) {
    this.make = make
    this.model = model
    this.year = year
    this.isForSale = isForSale
    this.isInStock = isInStock
  }

  toString() {
    return console.log(JSON.stringify(this))
  }
}

class CarBuilder {
  constructor(make, model, year) {
    this.make = make
    this.model = model
    this.year = year
  }

  notForSale() {
    this.isForSale = false

    return this
  }

  addInStock() {
    this.isInStock = true

    return this
  }

  build() {
    return new Car(
      this.make,
      this.model,
      this.year,
      this.isForSale,
      this.isInStock,
    )
  }
}

module.exports = CarBuilder
```

위 패턴을 사용하면 `Car` 대신에 `CarBuilder`를 사용하여 객체를 만들 수 있다.

```javascript
const CarBuilder = require('./CarBuilder')

const bmw = new CarBuilder('bmw', 'x6', 2020).addInStock().build()
const audi = new CarBuilder('audi', 'a8', 2021).notForSale().build()
const mercedes = new CarBuilder('mercedes-benz', 'c-class', 2019).build()
```

만약에 이런 빌더 패턴 없이 복잡한 객체를 만들게 되면 에러를 발생할 가능성이 커진다.

```javascript
const bmw = new CarBuilder('bmw', 'x6', 2020, true, true)
```

뒤 이어 있는 `true`가 각각 무엇을 의미하는지 알아야 하기 때문에 객체 생성이 복잡해 지고, 에러를 만들어낼 가능성이 커진다. 따라서 빌더 디자인 패턴은 복잡한 객체 생성과 사용을 분리하는데 도움을 준다.

## 프로토타입

자바스크립트는 프로토타입 기반 언어이기 때문에, 프로토타입으로 상속이 구현되어 있다. 이 말인 즉슨, 모든 객체는 어떤 객체를 상속하고 있다는 뜻이다.

따라서 이른바 예제 객체 라고 불리우는 프로토타입 객체의 값을 복제 하여 새로운 객체를 만든다. 이는 프로토 타입이 새 객체의 일종의 청사진 역할을 하는 것이다. 이 설계 패턴을 활용하면 객체에 정의된 함수가 참조에 의해 생성된다는 이점을 얻을 수 있다. 즉, 모든 객체가 해당 기능의 복사본을 보유하는 것이 아니라 동일한 기능을 가르키게 된다. 간단히 말해, 프로토타입 기능은 프로토타입에 상속된 모든 객체에 사용할 수 있다.

```javascript
const atv = {
  make: 'Honda',
  model: 'Rincon 650',
  year: 2018,
  mud: () => {
    console.log('Mudding')
  },
}

const secondATV = Object.create(atv)
```

프로토타입에서 새로운 객체를 생성하기 위해서는, `Object.create()`를 활용하면 된다. 두번째 객체인 `secondATV`는 첫번째 객체인 `atv`와 같은 값을 가지게 된다. `mud()`를 호출해보면 같은 값을 찍는 것을 알 수 있다.

프로토타입 디자인 패턴을 활용하는 다른 방법은 클래스 안에 프로토타입을 명시하는 것이다.

```javascript
const atvPrototype = {
  mud: () => {
    console.log('Mudding')
  },
}

function Atv(make, model, year) {
  function constructor(make, model, year) {
    this.make = make
    this.model = model
    this.year = year
  }

  constructor.prototype = atvPrototype

  let instance = new constructor(make, model, year)
  return instance
}

const atv1 = Atv()
const atv2 = Atv('Honda', 'Rincon 650', '2018')
```

마찬가지로 두 인스턴스 모두 `atv` 객체에 정의된 항목에 액세스 할 수 있다.

결론적으로, 프로토타입 설계 패턴은 객체가 동일한 기능 또는 속성을 공유하기를 원할 때 유용하다.

### 요약

- 자바스크립트는 프로토타입 기반 언어다.
- 프로토타입 기반 상속을 사용한다.
- 각 객체는 다른 객체로 부터 상속된다.
- 새 객체는 프로토타입이라는 일종의 청사진에 따라 생성된다.
- 프로토타입에 정의된 함수는 모든 새 클래스에서 상속된다.
- 새 클래스는 개별 복사본을 갖는 대신 동일한 기능을 가리킨다.
- 


옛날 스타일의 가능한 객체 지향 프로그래밍

개발자가 알아야 하는 4가지 nodejs 디자인 패턴

웹 사이트의 크기는 해가 갈 수록 커지고 있다. 3년 전과 비교 했을 때, 데스크톱 사이트는 20.5%, 모바일 웹 사이트의 경우에는 24.1%나 커졌다.

![total-kb](./images/website-total-kilobytes.png)

https://httparchive.org/reports/page-weight?start=2016_11_15&end=latest&view=list

다행히도(?) 단순히 사이즈만 커져가지는 않았다. 웹사이트 방문자들에게 가능한 최소한의 사이즈로 제공하기 위한 많은 노력들이 있다. 그중에 하나가 HTTP 압축이다.

## HTTP Compression

간단하게 얘기해서, 압축을 해서 웹서버에서 더 작은 파일을 서빙할 수 있도록 하는 기술이다. 사용자가 URL을 통해서 웹사이트에 접속을 하면, 브라우저는 웹서버가 압축을 해서 보낸 다는 것을 인지한다. 이러한 압축은 네트워크 요청을 빠르게 하여 가능한 로딩을 빠르게 도와준다. (압축을 푸는 것이 네트워크 요청보다 더 빠르므로)

### Gzip

이러한 압축 알고리즘으로 가장 널리 알려져 있는 것이 [gzip](https://ko.wikipedia.org/wiki/Gzip)이다. 최대 70%까지 사이즈를 줄여주는 가장 보편적인 압축 알고리즘이다. Gzip은 웹사이트 파일의 중복코드, 띄어쓰기의 양을 줄여서 동작하고, 9단계에 걸친 옵션을 제공하여 압축량과 압축에 걸리는 시간을 세세하게 조정할 수도 있다.

웹 사이트에서 Gzip을 제공하는 방법은 호스팅 공급자와 웹서버에 따라 달라진다.

아파치 서버의 경우, `.htacess`에 아래 코드를 추가하면 된다.

```bash
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
```

nginx의 경우에는 다음과 같다.

```bash
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary on;
```

> 물론 이거 같다 붙힌다고 만사 해결이 되는 것은 아니다. 반드시 세세한 설정을 거쳐야 한다.

이렇듯 gzip은 설치가 용이하고, 압축도 잘되며, 압축에 걸리는 시간도 빠르기 때문에 널리 사용되고 있다.

## Brotli

- https://github.com/google/brotli
- https://en.wikipedia.org/wiki/Brotli
- https://aws.amazon.com/ko/about-aws/whats-new/2020/09/cloudfront-brotli-compression/

2013년, 구글은 웹 폰트 압축을 위해 Brotli라는 새로운 압축 알고리즘을 만들었으며, 2년 뒤인 2015년에는 HTTP 압축에 사용할 버전을 만들었다. 이는 앞서 언급한 GZip에 비해 많은 우위를 가지고 있었다.

![css file size](https://miro.medium.com/max/2000/1*j-3dAHj0pu5E1GmtD6eMuw.png)

![javascript file size](https://miro.medium.com/max/2000/1*i3xJiqPfF84H1h2Rt7na9w.png)

![overall](https://miro.medium.com/max/1400/1*_GVXtCwykvrPzclpIcpAsw.png)

[이 글](https://certsimple.com/blog/nginx-brotli)에 따르면 Brotli를 활용했을 경우 자바스크립트 파일의 경우 gzip에 비해 14%, HTML은 21%, css는 17% 더 작게 만들어 준다고 나와있다.

https://tools.keycdn.com/brotli-test 에서 brotli를 지원하는지 확인할 수 있다.

![yceffort blog](./images/yceffort-brotli.png)

> content-encoding이 br로 되어 있으면 brotli를 사용한다는 뜻이다.

### 적용하는 방법

**apache**

```bash
<VirtualHost *:443>
…
…
RewriteEngine On
RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}.br -f
RewriteRule ^(.*)$ $1.br [L]
RewriteRule ".br$" "-" [NS,E=no-gzip:1,E=dont-vary:1]
<Files *.js.br>
 AddType "text/javascript" .br
 AddEncoding br .br
</Files>
<Files *.css.br>
 AddType "text/css" .br
 AddEncoding br .br
</Files>
<Files *.svg.br>
 AddType "image/svg+xml" .br
 AddEncoding br .br
</Files>
<Files *.html.br>
 AddType "text/html" .br
 AddEncoding br .br
</Files>
</VirtualHost>
```

[nginx-brotli](https://github.com/google/ngx_brotli)를 설치하여 제공할 수 있다.

**nginx**

```bash
http{
 brotli_static on;
 brotli_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;
}
```

자세한 내용은 https://www.tezify.com/how-to/use-brotli-compression/ 를 참조.

주의 할 것은, jpg, jpeg와 같이 이미 압축되어 있는 컨텐츠를 다시 압축할 필요는 없다는 것이다. 또한 html, js만 압축할 것이 아니라 xml, json등의 파일도 압축 대상에 포함시켜야 한다.

## 그러나

그러나 brotli는 ie에서 지원하지 않는다.

https://caniuse.com/brotli

![can-i-use-brotli](./images/can-i-use-brotli.png)

따라서, ie 환경을 고려하고 있다면 gzip 방식으로도 컨텐츠를 제공해야 한다.

왜 이걸 이제 알았나 자괴감 들고 괴로워

더 나은 압축 알고리즘, Brotli

웹 사이트의 크기는 해가 갈 수록 커지고 있다. 3년 전과 비교 했을 때, 데스크톱 사이트는 20.5%, 모바일 웹 사이트의 경우에는 24.1%나 커졌다.
<img src="./images/website-total-kilobytes.png" alt="total-kb">
<a href="https://httparchive.org/reports/page-weight?start=2016_11_15&#x26;end=latest&#x26;view=list">https://httparchive.org/reports/page-weight?start=2016_11_15&#x26;end=latest&#x26;view=list</a>
다행히도(?) 단순히 사이즈만 커져가지는 않았다. 웹사이트 방문자들에게 가능한 최소한의 사이즈로 제공하기 위한 많은 노력들이 있다. 그중에 하나가 HTTP 압축이다.
<h2 id="http-compression">HTTP Compression</h2>
간단하게 얘기해서, 압축을 해서 웹서버에서 더 작은 파일을 서빙할 수 있도록 하는 기술이다. 사용자가 URL을 통해서 웹사이트에 접속을 하면, 브라우저는 웹서버가 압축을 해서 보낸 다는 것을 인지한다. 이러한 압축은 네트워크 요청을 빠르게 하여 가능한 로딩을 빠르게 도와준다. (압축을 푸는 것이 네트워크 요청보다 더 빠르므로)
<h3 id="gzip">Gzip</h3>
이러한 압축 알고리즘으로 가장 널리 알려져 있는 것이 <a href="https://ko.wikipedia.org/wiki/Gzip">gzip</a>이다. 최대 70%까지 사이즈를 줄여주는 가장 보편적인 압축 알고리즘이다. Gzip은 웹사이트 파일의 중복코드, 띄어쓰기의 양을 줄여서 동작하고, 9단계에 걸친 옵션을 제공하여 압축량과 압축에 걸리는 시간을 세세하게 조정할 수도 있다.
웹 사이트에서 Gzip을 제공하는 방법은 호스팅 공급자와 웹서버에 따라 달라진다.
아파치 서버의 경우, <code>.htacess</code>에 아래 코드를 추가하면 된다.
<pre class="language-bash"><code class="language-bash">AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</code></pre>
nginx의 경우에는 다음과 같다.
<pre class="language-bash"><code class="language-bash">gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary on;
</code></pre>
<blockquote>
물론 이거 같다 붙힌다고 만사 해결이 되는 것은 아니다. 반드시 세세한 설정을 거쳐야 한다.
</blockquote>
이렇듯 gzip은 설치가 용이하고, 압축도 잘되며, 압축에 걸리는 시간도 빠르기 때문에 널리 사용되고 있다.
<h2 id="brotli">Brotli</h2>
<ul>
<li><a href="https://github.com/google/brotli">https://github.com/google/brotli</a></li>
<li><a href="https://en.wikipedia.org/wiki/Brotli">https://en.wikipedia.org/wiki/Brotli</a></li>
<li><a href="https://aws.amazon.com/ko/about-aws/whats-new/2020/09/cloudfront-brotli-compression/">https://aws.amazon.com/ko/about-aws/whats-new/2020/09/cloudfront-brotli-compression/</a></li>
</ul>
2013년, 구글은 웹 폰트 압축을 위해 Brotli라는 새로운 압축 알고리즘을 만들었으며, 2년 뒤인 2015년에는 HTTP 압축에 사용할 버전을 만들었다. 이는 앞서 언급한 GZip에 비해 많은 우위를 가지고 있었다.
<img src="https://miro.medium.com/max/2000/1*j-3dAHj0pu5E1GmtD6eMuw.png" alt="css file size">
<img src="https://miro.medium.com/max/2000/1*i3xJiqPfF84H1h2Rt7na9w.png" alt="javascript file size">
<img src="https://miro.medium.com/max/1400/1*_GVXtCwykvrPzclpIcpAsw.png" alt="overall">
<a href="https://certsimple.com/blog/nginx-brotli">이 글</a>에 따르면 Brotli를 활용했을 경우 자바스크립트 파일의 경우 gzip에 비해 14%, HTML은 21%, css는 17% 더 작게 만들어 준다고 나와있다.
<a href="https://tools.keycdn.com/brotli-test">https://tools.keycdn.com/brotli-test</a> 에서 brotli를 지원하는지 확인할 수 있다.
<img src="./images/yceffort-brotli.png" alt="yceffort blog">
<blockquote>
content-encoding이 br로 되어 있으면 brotli를 사용한다는 뜻이다.
</blockquote>
<h3 id="적용하는-방법">적용하는 방법</h3>
apache
<pre class="language-bash"><code class="language-bash">&#x3C;VirtualHost *:443>
…
…
RewriteEngine On
RewriteCond %{HTTP:Accept-Encoding} br
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}.br -f
RewriteRule ^(.*)$ $1.br [L]
RewriteRule ".br$" "-" [NS,E=no-gzip:1,E=dont-vary:1]
&#x3C;Files *.js.br>
 AddType "text/javascript" .br
 AddEncoding br .br
&#x3C;/Files>
&#x3C;Files *.css.br>
 AddType "text/css" .br
 AddEncoding br .br
&#x3C;/Files>
&#x3C;Files *.svg.br>
 AddType "image/svg+xml" .br
 AddEncoding br .br
&#x3C;/Files>
&#x3C;Files *.html.br>
 AddType "text/html" .br
 AddEncoding br .br
&#x3C;/Files>
&#x3C;/VirtualHost>
</code></pre>
<a href="https://github.com/google/ngx_brotli">nginx-brotli</a>를 설치하여 제공할 수 있다.
nginx
<pre class="language-bash"><code class="language-bash">http{
 brotli_static on;
 brotli_types text/plain text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/vnd.microsoft.icon image/bmp image/svg+xml;
}
</code></pre>
자세한 내용은 <a href="https://www.tezify.com/how-to/use-brotli-compression/">https://www.tezify.com/how-to/use-brotli-compression/</a> 를 참조.
주의 할 것은, jpg, jpeg와 같이 이미 압축되어 있는 컨텐츠를 다시 압축할 필요는 없다는 것이다. 또한 html, js만 압축할 것이 아니라 xml, json등의 파일도 압축 대상에 포함시켜야 한다.
<h2 id="그러나">그러나</h2>
그러나 brotli는 ie에서 지원하지 않는다.
<a href="https://caniuse.com/brotli">https://caniuse.com/brotli</a>
<img src="./images/can-i-use-brotli.png" alt="can-i-use-brotli">
따라서, ie 환경을 고려하고 있다면 gzip 방식으로도 컨텐츠를 제공해야 한다.

https://github.com/tc39/ecma402/milestone/4

## String replaceAll()

String에서 replace를 하기 위해서는 `.replace('origin', 'change')` 를 썼지만, 모든 글자를 바꾸기 위해서는 `gi`를 활용해서 정규식 변환을 했었어야 했다.

```javascript
const a = '123123123'
a.replace('1', 'a') // "a23123123"
a.replace(/1/gi, 'a') // "a23a23a23"
```

이제 `replaceAll()`을 사용하면 된다.

```javascript
a.replaceAll(1, 'a') // "a23a23a23"
a.replace(/1/gi, 'a') === a.replaceAll(1, 'a') //true
```

## 논리적 할당 연산 (Logical Assignment Operator)

말이 조금 어렵지만(?) 밑에 예제를 보 면 알수 있다.

```javascript
let a = true
let b = 2
let c = 3

// 왼쪽이 참이면 a에 b를 할당한다.
a && (a = b)

a &&= b

// 왼쪽이 거짓이면 a에 b를 할당한다.
a || (a = b)
// 위 식은 아래와 같다
a ||= b

// 왼쪽이 nullish (null, undefined) 면 a를 b에 할당한다.
a ?? (a = b)
// 위 식은 아래와 같다
a ??= b
```

## 숫자 연산자 (Numeric Separators)

```javascript
const a = 1000000
const b = 1_000_000
const c = 1_000_000.123_456
const d = 1000000.123456

a === b // true
c === d // true
```

숫제가 길어지면 `,`를 찍는데, 이제 그것이 자바스크립트에서도 가능해진 것이다. 순전히 사람을 위한 기능이라고 보면 될것 같다.

## Promise.any()

`Promise.all()`과는 다르게, 배열중에 하나라도 먼저 끝나는게 있으면 그 결과를 리턴한다.

```javascript
const promise1 = new Promise((resolve) => setTimeout(resolve, 100, 'first'))
const promise2 = new Promise((resolve) => setTimeout(resolve, 300, 'second'))
const promise3 = new Promise((resolve) => setTimeout(resolve, 500, 'third'))

const promises = [promise1, promise2, promise3]

Promise.any(promises).then((value) => console.log(value))
```

만약 이 중에 하나라도 resolve가 되지 않으면, `AggregateError`를 리턴한다. 이 에러는 배열안의 모든 에러를 하나로 합쳐서 보여준다.

## WeakRef

자바스크립트에서는, 객체는 항상 강하게 참조되었다. 이 말은, 참고하고 있는 객체가 존재하는 이상, 절대로 메모리 내에서 객체가 가비지 컬렉팅이 되지 않는다는 것이다.

```javascript
var a, b
a = b = document.querySelector('.someClass')
a = undefined

// b는 여전히 document.querySelector('.someClass')를 참조한다.
```

위 예제에서는, 객체를 메모리에 계속해서 남겨 두고 싶지 않기 때문에, `WeakRef`를 사용하여 캐시나 큰 객체의 매핑을 구현할 수 있다. 사용하지 않는 경우에는, 메모리를 가비지 컬렉팅하여 필요할 때 마다 새로운 캐시를 생성할 수 있다.

```javascript
const x = new WeakRef(document.querySelector('.gatsby-highlight'))
const element = x.deref()
```

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakRef

그러나 이 `WeakRef`는 가능한 사용을 피하라고 언급되어 있다. 가비지 컬렉터가 작동하는 타이밍, 방법, 및 실행 여부는 자바스크립트 엔진 구현에 따라 달려 있기 때문에 자바스크립트 엔진 마다 이 동작이 달라질 수 있기 때문이다.

2021년엔 쓸만한 개발자가 되길 바라며

yceffort

overflow: auto vs overflow: scroll 왜 윈도우에서만 쓸모없는 스크롤바가 노출될까

그런데 왜 brotli를 사용하지 않는 것일까? 🤔

개발자가 알아야 하는 4가지 nodejs 디자인 패턴

더 나은 압축 알고리즘, Brotli

ES2021 미리보기