[이 전 블로그 포스팅](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를 사용하지 않는 것일까? 🤔

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

- 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 디자인 패턴

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년엔 쓸만한 개발자가 되길 바라며

ES2021 미리보기

```javascript
function sayHello(name) {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve(`Hello, ${name}`), 2000)
  })
}

const message1 = await sayHello('yceffort')
console.log(message1)
```

요런 비동기 함수가 있고, 이를 map으로 처리한다고 가정해보자.

```javascript
const names = [
  'yceffort1',
  'yceffort2',
  'yceffort3',
  'yceffort4',
  'yceffort5',
  'yceffort6',
]

const messages = names.map(async (name) => await sayHello(name))
console.table(messages)
```

이렇게 하면 될 것 같지만?

```
(6) [Promise, Promise, Promise, Promise, Promise, Promise]
0: Promise {<pending>}
1: Promise {<pending>}
2: Promise {<pending>}
3: Promise {<pending>}
4: Promise {<pending>}
5: Promise {<pending>}
```

아쉽게도 모든 결과가 pending으로 뜬다. `await`은 `Promise` 객체만 기다려 주기 때문에 그런 것으로 보인다. 반변에 우리가 넘긴 것은 `list`다.

따라서 이를 정상적으로 실행하기 위해서는 `Promise.all`을 사용해야 한다.

```javascript
const promiseMessages = await Promise.all(
  names.map(async (name) => await sayHello(name)),
)
console.log(promiseMessages)
```

```javascript
;[
  'Hello, yceffort1',
  'Hello, yceffort2',
  'Hello, yceffort3',
  'Hello, yceffort4',
  'Hello, yceffort5',
  'Hello, yceffort6',
]
```

그렇다면 `reduce`의 경우에는 어떻게 처리하면 좋을까?

```javascript
const oddMessages = names.reduce(async (prev, current, index) => {
  if (index % 2 > 0) {
    return [...prev, await sayHello(current)]
  } else {
    return prev
  }
}, [])
```

이렇게 하면 당연히 안될 것이다. 여기에서 `prev`는 기존의 값이 아닌 `Promise`일 것이다.

```javascript
const oddMessages = await names.reduce(async (prev, current, index) => {
  const prevResult = await prev.then()
  if (index % 2 === 0) {
    const result = await sayHello(current)
    return Promise.resolve([...prevResult, result])
  } else {
    return Promise.resolve(prevResult)
  }
}, Promise.resolve([]))
```

기존에 있던 모든 return을 `Promise.resolve`로 감싸고, 이전에 넘어온 `prev`는 `then`처리를 했다.

```javascript
;['Hello, yceffort1', 'Hello, yceffort3', 'Hello, yceffort5']
```


map과 reduce에서 async await 사용하기

오늘날 90%가 넘는 브라우저가 모던 자바스크립트를 실행할 수 있음에도 불구하고, 레거시 자바스크립트는 오늘날 웹 성능 문제에 큰 원인 중 하나로 남아 있다. ES2017 문법을 사용하여 웹 페이지 또는 패키지를 작성하고 퍼블리싱 하면 성능을 매우 향상 시킬 수 있다.

## 모던 자바스크립트란 무엇일까

모던 자바스크립트는 특정 ECMAScript 버전으로 작성된 코드를 말하는게 아니고, 모던 브라우저에서 지원하는 문법으로 이루어진 것을 의미한다. 크롬, 엣지, 파이어폭스, 사파리와 같은 모던 웹 브라우저는 브라우저 시장의 90% 이상을 차지하고 있으며, 이 렌더링 엔진에 의존하는 다른 브라우저가 5% 쯤 된다. 따라서 글로벌 웹 트래픽의 95%가 지난 10년간 가장 널리 사용되는 자바스크립트 언어 기능을 지원하는 브라우저에서 비롯된다.

> 아마도 엣지 레거시와 구 IE를 제거한 수치로 보면 될 것 같다. 우리나라에서는 약 93% 정도 된다.

<div id="all-browser-KR-monthly-201912-202011" width="600" height="400" style="width:600px; height: 400px;"></div><p>Source: <a href="https://gs.statcounter.com/browser-market-share/all/south-korea/#monthly-201912-202011-bar">StatCounter Global Stats - Browser Market Share</a></p><script type="text/javascript" src="https://www.statcounter.com/js/fusioncharts.js"></script><script type="text/javascript" src="https://gs.statcounter.com/chart.php?all-browser-KR-monthly-201912-202011&chartWidth=600"></script>

여기서 말하는 문법은 이정도다.

- 클래스 (ES2015)
- 화살표 함수 (ES2015)
- 제네레이터 (ES2015)
- 블록 스코프 (ES2015)
- 디스트럭쳐링 (ES2015)
- 전개 연산자 (ES2015)
- 객체 축약 (ES2015)
- async await (ES2017)

이 후에 나온 기능, 예를 들어 ES2020, ES2021에 나온 기능들은 브라우저의 70% 정도가 지원한다. 여전히 70%면 많은 수치이지만, 그 기능에 온전히 기대는 것은 안전하지 않다. 따라서 모던 자바스크립트를 타겟으로 한다면, 가장 널리 알려져 있으며 지원하는 브라우저가 많은 ES2017 정도가 적당해 보인다. 다른 말로 하자면,  ES2017이 오늘날의 가장 모던한 문법인 것이다.

> 물론 이 글은 2020년 12월 15일에 작성되어 있습니다. 시간이 흐르면 더 달라지겠죠?

https://dev.to/garylchew/bringing-modern-javascript-to-libraries-432c

## 레거시 자바스크립트

레거시 자바스크립트란 위에서 언급한 새로운 기능을 사용하지 않은 코드라 볼 수 있다. 대부분의 개발자는 모던한 문법으로 작성하지만, 브라우저의 지원을 늘리기 위하여 레거시 구문으로 컴파일한다🤪. 레거시 구문으로 컴파일하면 브라우저 지원 범위가 증가하지만, 그 효과는 우리가 생각하는 것보다 작다. 레거시 자바스크립트로 95% 정도의 수치를 98% 로 늘릴 수 는 있지만, 그 비용은 엄청나다.

> 나머지 2%는 no javascript 가 아닐까 싶습니다

- 레거시 자바스크립트는 모던 자바스크립트와 비교 했을 때 일반적으로 20% 정도 용량이 더 크고 느리다. 만약 여기에서 잘못 구성한다면 그 차이가 더 커질 수 있다.
- 별도로 설치하는 자바스크립트 라이브러리의 경우 일반적인 자바스크립트 코드의 90% 정도를 차지 한다. 이 코드에 폴리필 등이 추가 된다면 더 많은 자바스크립트 오버헤드가 발생할 수 있다.

## npm에서 모던 자바스크립트

[최근에 nodejs는 패키지의 엔트리 포인트를 지정할 수 있게 해주었다.](https://nodejs.org/api/packages.html#packages_package_entry_points)

```json
{
  "exports": "./index.js"
}
```

`exports` 필드에서 참조하는 모듈은 최소 ES2019를 지원하는 12.8의 노드 버전을 의미한다. 따라서 exports를 참조하는 모듈은 모던 자바스크립트로 작성할 수 있음을 의미한다. 따라서 모던 코드만 있는 패키지를 배포하고, 트랜스파일링은 사용하는 사람에게 맡기고 싶다면 위처럼 `exports` 필드만 사용하면 된다.

`exports`와 함께 `main`을 사용한다면, 레거시 브라우저를 위한 ES5와 CommonJS를 제공할 수 있다. 일종의 modern 한 코드의 레거시 폴백이다.

```json
{
  "name": "foo",
  "exports": "./modern.js",
  "main": "./legacy.cjs"
}
```

CommonJS로 작성된 fallback에, `module`을 추가한다면 유사하게 legacy fallback 번들로 동작하지만, 자바스크립트 모듈 문법인 `import`와 `export`도 사용 가능하다.

```json
{
  "name": "foo",
  "exports": "./modern.js",
  "main": "./legacy.cjs",
  "module": "./module.js"
}
```

이렇게 하는 이유는, 웹팩과 롤업과 같은 번들러에서 트리쉐이킹을 할 수 있도록 하기 위해서다. 이 코드는 `import` `export` 이외에 모던 코드를 사용하지 않는 레거시 번들 이므로, 레거시 코드를 지원함과 동시에 번들링에 최적화 시킬 수 있다는 장점을 가지고 있다.

## 애플리케이션의 모던 자바스크립트

써드파티 디펜던시는 프로덕션 웹 애플리케이션의 대부분을 차지한다. npm 의존성은 역사적으로 레거시 ES5로 퍼블리싱 되어왔지만, 이에 의존하는 것은 더이상 안전하지 못한 가정이며, 애플리케이션에서 브라우저 지원을 해칠 수도 있는 위험한 행동이다.

모던 자바스크립트로 이동하는 npm 패키지가 점차 많아지면서 이를 다룰 수 있는 도구를 설치하는 것이 중요 해졌다. 여거라지 방법이 있지만, 일반적으로 좋은 아이디어는 의존성을 내가 작성하는 코드의 문법 수준과 맞춰 트랜스파일 하는 것이다.

## 웹팩

웹팩5에서 부터, 번들 및 모듈에 대한 코드를 생성할 때 마다 사용할 문법을 설정할 수 있다. 이는 코드나 의존성을 트랜스파일링 하는 것이 아니고, 오직 webpack에 의해 생성된 코드를 붙일 때 영향을 미친다. 브라우저 지원 타겟을 설저하기 위해서는 `browserlist`설정을 추가하거나, 혹은 웹팩 설정에 바로 넣어두면 된다.

```javascript
module.exports = {
  target: ['web', 'es2017'],
};
```

또한 웹팩에서 모던 ES 모듈 환경을 타겟으로 한다면, 불필요한 wrapper 함수를 생략하여 번들 크기를 최적화하는 설정을 할 수 다.

```javascript
module.exports = {
  target: ['web', 'es2017'],
  output: {
    module: true,
  },
  experiments: {
    outputModule: true,
  },
};
```

이외에도 웹팩을 활용하여 모던 자바스크리븥 문법을 활용하면서 동시에 레거시 브라우저도 지원할 수 있도록 도와주는 많은 도구들이 존재한다.

## Optimize Plugin

[Optimize Plugin](https://github.com/developit/optimize-plugin)은 개별 자바스크립트 파일을 레거시 자바스크립트로 만드는 대신에, 최종적으로 만들어진 모던 번들 코드를 레거시 자바스크립트로 변환시켜주는 도구다. 웹팩 설정을 통해 모든 것이 모던 자바스크립트라고 가정하기 때문에, 특별한 처리가 필요하지 않다. 또한 이는 개별 모듈이 아닌 번들 레벨에서 동작하므로 애플리케이션의 코드와 디펜던시를 동등하게 처리한다. 이는 최종 번들링된 파일을 다시 레거시 문법으로 만드는 것이기 때문에, 전통적인 방식보다 빠를 수 있다. 이러한 두개의 모듈은 [module/nomodule pattern](https://web.dev/serve-modern-code-to-modern-browsers/)에서 사용된다.

```javascript
// webpack.config.js
const OptimizePlugin = require('optimize-plugin');

module.exports = {
  // ...
  plugins: [new OptimizePlugin()],
};
```

`Optimize Plugin`은 모던 코드와 레거시 코드를 따로 번들링 하는 기존 방식보다 더 빠르고 효율적이다. 또한 `Babel`처리도 가능하며, `Terser`를 활용하여 각각의 번들 크기를 줄일 수도 있다. 마지막으로, 레거시 번들에 필요한 폴리필을 따로 관리하기 때문에, 모던 브라우저에서 이를 로딩하지 않도록 도와준다.

<video style="width: 100%;" controls="" autoplay="" loop="" muted="" class="w-screenshot">
    <source src="https://storage.googleapis.com/web-dev-assets/fast-publish-modern-javascript/transpile-before-after.webm" type="video/webm">
    <source src="https://storage.googleapis.com/web-dev-assets/fast-publish-modern-javascript/transpile-before-after.mp4" type="video/mp4">
  </video>

  ## BabelEsmPlugin

  웹팩 플러그인 중 하나인 [BabelEsmPlugin](https://github.com/prateekbh/babel-esm-plugin)는 `@babel/preset-env` 와 함께 사용할 수 있으며, 현재 가지고 있는 번들을 모던 브라우저에 서비스 할 수 있도록 트랜스파일링을 최소화 해준다. 이는 Next.js나 preact cli에서도 사용하는 가장 유명한 module/nomodule 솔루션이다.

  ```javascript
  // webpack.config.js
const BabelEsmPlugin = require('babel-esm-plugin');

module.exports = {
  //...
  module: {
    rules: [
      // your existing babel-loader configuration:
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
  plugins: [new BabelEsmPlugin()],
};
```

`BabelEsmPlugin`는 애플리케이션에서 크게 분리된 두가지 빌드를 실행하기 때문에 다양한 웹팩 설정을 지원한다. 두 번 컴파일 하는 것은 대규모 애플리케이션에 약간의 추가 시간이 걸릴 수 있지만, 이는 BabelEsmPlugin이 기존의 웹팩 설정에 원활한 통합 등을 도와주며, 편의성도 제공한다.

## node_modules을 트랜스파일 하기 위한 babel-loader 설정

위에서 언급한 두개의 플러그인 대신 `babel-loader`를 사용하고 있다면, npm 모듈을 모던 자바스크립트로 사용하기 위한 중요한 단계가 남아 있다. 두개의 개별적인 바벨 로더를 구성해서 정의한다면, node_modules에서 발견되는 최신 언어 스펙을 ES2017로 자동으로 컴파일 하는 동시에, 프로젝트에 구성된 babel 플러그인과 사전 설정으로 자신의 코드를 1차적으로 변환할 수 있다. 이는 module/nomodule 설정의 번들을 생성하지는 않지만, 오래된 브라우저 지원을 깨트리지 않고 모던 자바스크립트가 포함된 npm 패지키를 설치하고 사용하는 것을 가능하게 한다. 

[webpack-plugin-modern-npm](https://www.npmjs.com/package/webpack-plugin-modern-npm) 을 사용하면, npm 디펜던시에 `exports`가 있는 코드들을 컴파일한다.

```javascript
// webpack.config.js
const ModernNpmPlugin = require('webpack-plugin-modern-npm');

module.exports = {
  plugins: [
    // auto-transpile modern stuff found in node_modules
    new ModernNpmPlugin(),
  ],
};
```

대신에 이 기능을 수동으로 설정할 수 도 있다.

```javascript
// webpack.config.js
module.exports = {
  module: {
    rules: [
      // Transpile for your own first-party code:
      {
        test: /\.js$/i,
        loader: 'babel-loader',
        exclude: /node_modules/,
      },
      // Transpile modern dependencies:
      {
        test: /\.js$/i,
        include(file) {
          let dir = file.match(/^.*[/\\]node_modules[/\\](@.*?[/\\])?.*?[/\\]/);
          try {
            return dir && !!require(dir[0] + 'package.json').exports;
          } catch (e) {}
        },
        use: {
          loader: 'babel-loader',
          options: {
            babelrc: false,
            configFile: false,
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
};
```

이 방법을 사용할 때는 minifier가 이러한 모던 코드를 지원할 수 있도록 해야 한다. `Terser` `Uglify-es`에 `{ecma: 1027}`를 지정할 수 있는 옵션이 있으며, 경우에 따라 압축하거나 포맷하는 와중에 `ES2017`구문을 생성하기도 한다. 

## 추가적인 빌드 툴

- https://parceljs.org/
- https://www.snowpack.dev/
- https://github.com/vitejs/vite
- https://github.com/preactjs/wmr

## 결론

ES2017 이 요즘 흔히 말하는 모던 자바스크립트에 가장 근접한 스펙이며, npm, babel, rollup 등을 빌드 시스템에 사용하여 패키지와 문법을 모던 자바스크립트에서 동작할 수 있도록 설정할 수 있다. 

출처: https://web.dev/publish-modern-javascript/

아니 그래서 IE 11 언제 없앨 건데요

yceffort

javascript

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

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

ES2021 미리보기

map과 reduce에서 async await 사용하기

더 빠른 웹 애플리케이션을 위한 모던 자바스크립트