[TIL] Naver FE News 2023-11

[TIL] Naver FE News는 Naver FE 팀에서 매월 첫째주 수요일에 업로드하는 FE 관련 이슈들을 팔로우 하면서 관심있는 내용을 학습하고 정리하는 컨텐츠입니다. [ https://github.com/naver/fe-news ]

1. 클로저 컴파일러의 역사, 타입스크립트가 승리한 이유

https://ktseo41.github.io/blog/log/the-saga-of-the-closure-compiler-and-why-typescript-won.html

클로저 컴파일러의 역사, 그리고 타입스크립트가 승리한 이유 | bohyeon.dev

 

• 클로저 컴파일러(Closure Compiler)란 과거 구글에서 개발한 대규모 자바스크립트 애플리케이션을 만들기 위해 사용하던 도구이다. (타입스크립트와 비슷한 source to source 컴파일러)
• 현재 자바스크립트 진영에서 타입스크립트의 완승은 부정할 수 없지만 아래 이유로 클로저 컴파일러를 다시 살펴보는 것은 흥미롭다.
  • 타입스크립트와 다르게 높은 수준의 설계 결정(feat. google)을 내린 시스템임
  • 타입스크립트에 누락된 미처 생각하지 못했던 영역을 볼 수 있음
  • 자바스크립트 역사의 중요한 부분임
• 타입스크립트는 자바스크립트의 상위 집합(superset)이다. 반면에 클로저 코드는 자바스크립트다.
  • JSDoc 스타일의 주석을 통해 타입을 추가
  • 타입 커버리지를 자체적으로 제공
  • 변수 이름 난독화를 통해 코드 용량 경량화 (valueNameSomething => a)
    • 타입스크립트는 코드 경량화를 크게 신경쓰지 않는다.
    • 경량화의 문제점
      • 난독화는 예상치 못한 에러를 발생시키기도 하기 때문에 무조건 좋은 것은 아니다.
      • 객체 프로퍼티 접근 시 대괄호(obj['valueName'])로 접근하는 방식은 난독화 되지 않고 점으로 묶인 프로퍼티(obj.valueName)는 난독화 된다는 규칙이 있었다. 이를 모르고 개발하면 당연히 에러가 발생한다.
      • 서드파티 라이브러리는 이를 염두에 두고 개발하지 않을 가능성이 매우 크기 때문에 문제가 발생한다.(React도 못씀.....)
• 구글은 2009년 말까지 클로저 컴파일러를 오픈소스로 공개하지 않았다.
• 클로저 컴파일러는 자바스크립트를 피해야 하는 "나쁜 언어"로 인식하던 시절에 개발되었다.
• 여러가지 유용한 매서드를 만들때 goog.require 같이 goog이라는 네임스페이싱 컨벤션이 있었다. 이는 facebook/react가 아니라 그냥 react를 import 함으로써 가져가는 이점을 모두 잃게 만들었다.
• JS가 체계화되고 ES6 이상 발전하면서 클로저 컴파일러와의 기능적인 충돌이 있었고 표준을 따라가지 못했다. 하지만 이러한 중요한 변화가 타입스크립트에서는 개발 초기에 발생했고 유연하게 흡수할 수 있었다.
• 결론적으로, 클로저 컴파일러의 copyright이 2009라고 적혀있는 것에서 알 수 있듯이 이는 사장된 기술이지만 타입스크립트의 경량화에 관심이 있다면 한 번쯤 공부해보는 것도 좋을 것입니다.

 

2. HTTP/3 Performance for JS Developers

https://portal.gitnation.org/contents/http3-performance-for-js-developers

HTTP/3 Performance for JS Developers by Robin Marx - GitNation

 

1. Intro (HTTP2 = "H2", HTTP3 = "H3")
   • TCP 기반의 프로토콜인 H2와 달리 H3는 QUIC이라 불리는 UDT 기반의 프로토콜로 통신한다.
   • H3는 H2보다 더 나은 성능을 제공하면서 H2에서 넘어가기에 많은 비용(시간, 노력)을 요구하지 않는다.
   • zero RTT는 H3의 커넥션 시간을 줄여주는 핵심적인 성능 특징 중의 하나이다.
   • TCP의 three hand shake와 비교했을 때 QUIC은 transport와 TLS 암호화 과정을 하나로 통합한다.
   • 하지만 H3는 개발자가 의도적으로 명시하고 컨트롤 할 수 있는 영역이 제한적이라는 단점이 있다.
2. Zero RTT의 한계
   
   • Zero RTT는 브라우저(서버)가 선택해서 제공하는 기능이다.
   • 보안상의 이유로 Zero RTT가 배포 시 제한되는 경우가 많다.
   • 예를 들어 Zero RTT 요청은 매개변수가 없는 단순한 GET 요청에만 적용되는 식이다.
   • 따라서, 그 효용성에 비해 활용도가 별로 높지 않을 수 있다.
3. 리소스 로딩 및 우선순위 지정
   • H3는 브라우저가 제공하는 기능으로 개발자가 모든 내용을 다 알 필요 없고 지금부터 소개할 기능들을 기억하고 필요한 경우 프로젝트에 잘 활용하기만 하면 된다.
   • H2와 H3는 리소스를 로딩하기 위해 하나의 네트워크 연결을 맺는다. 따라서, 로딩 우선 순위를 잘 지정해야 한다.
   • 기본적으로 화면을 나타낼 때, 로딩 우선순위를 결정하는 것은 브라우저다.
   • H3에서는 이를 헤더에 정의하고 예측 가능하도록 설정할 수 있다.(개발자 도구에서도 볼 수 있음)
   • 하지만 이를 브라우저가 100% 신뢰하고 적용하지는 않기 때문에 예측하지 않은 동작을 야기할 수 있다.
4. Font와 JS에 대한 브라우저의 우선순위
   • 브라우저의 우선순위에 동의는 중요하다. (특히 크롬에서)
   • 크롬은 폰트를 중요하게(우선순위 높게) 생각하지만 파이어폭스는 반대다.
   • head에 작성된 자바스크립트는 우선순위가 높다.
   • 하지만 다른 자바스크립트는 브라우저마다 우선순위가 다르다.
   • 파이어폭스에서는 무조건 중간 우선순위를 준다.
   • 사파리는 무조건 높은 우선순위를 주고, async 설정 시에만 중간 우선순위를 준다.
   • 크롬은 좀 더 세밀하게 나누는데, 기본이 중간 우선순위고 async 설정 시 낮은 우선순위를 준다.
   • preload 설정 시에는 높은 우선순위를 준다.

3. 유용한 도구들

BlockNote

• Notion 느낌의 블럭형 텍스트 에디터를 사용할 수 있게 해주는 라이브러리
• 현 시점 기준 버전 태그가 0.10.1인 것으로 보아 개발 단계이지만 stable한 버전에 거의 다다른 것 같다.