읽은 글들 (~24.10.31)
JavaScript
Why is CSS-in-JS slow?
styled components 같은 CSS-in-JS 라이브러리가 느린 이유를 설명하는 글. 설명이 자세하기도 하거니와 적절한 다이어그램도 첨부되어 있어 쉽게 읽을 수 있다. 따라서 원문을 읽는 걸 추천한다. 아래부터는 간단한 요약이다.
일반적인 vanilla CSS 는 아래와 같은 과정을 거쳐 적용된다.
- HTML 파싱
- 1번 과정 중
<head />안에서 CSS 를 발견함 - CSS 파싱
- HTML 과 CSS 를 같이 적용해서 사용자에게 보여줌
하지만 CSS-in-JS 라이브러리들은 아래와 같은 과정을 거쳐야 한다.
- HTML 파싱
- HTML 을 사용자에게 보여줌
<body />안에서<script />를 발견함- JS 파싱
- JS 까지 적용된 결과를 사용자에게 보여줌
- CSS-in-JS 라이브러리가 CSS 를 생성함
- CSS 파싱
- CSS 까지 적용된 결과를 사용자에게 보여줌
따라서 느리다.
Vanilla Extract 같은 일부 라이브러리가 기존 CSS-in-JS 라이브러리들보다 빠른 이유는 런타임에서 CSS 를 생성하는 것이 아니라 컴파일 단계에서 미리 생성하기 때문.
[번역] 자바스크립트 정규 표현식의 환골탈태: 정규식의 역사와 미래를 톺아보며
자바스크립트는 원래 정규 표현식 기능이 강력하지 않았는데, 하나씩 개선되면서 현재는 매우 좋아졌고, 그럼에도 아직 있는 불편한 점은 라이브러리를 써서 충분히 극복 가능하다는 내용의 글.
대학생 시절 자바스크립트 정규 표현식은 lookbehind 도 되지 않아서 어이가 없었던 기억이 있는데, 이제는 lookbehind 를 포함해 많은 기능을 지원한다. 특히 named capture 와 유니코드 문자 지원이 인상깊다.
A list of JavaScript engines, runtimes, interpreters
자바스크립트 엔진/런타임/인터프리터를 정리한 목록. 생각보다 되게 많다.
Why I’m skeptical of rewriting JavaScript tools in “faster” languages
자바스크립트 툴들이 자바스크립트가 아닌 다른 더 빠른 언어로 재작성되는 것에 대한 우려를 정리한 글.
- 브라우저 생태계에서 자바스크립트는 이미 충분히 빠르다.
- 웹어셈블리가 사용되는 경우도 있긴 하지만 이것은 CPU 집약적인 작업을 구현하는 데 한정되어 사용된다.
- 자바스크립트 생태계는 빠른 것(=성능)보다는 작동하는 것을 만드는 데 더 집중해왔다. 툴들의 개발이 안정화된 시점에서 "더 빠른 언어"로 재작성하는 것은, 단순히 더 빠른 언어로 작성했기 때문에 성능이 오른 것이 아니라 성능을 염두에 두고 다시 설계했기 때문일 가능성이 크다.
- 성능을 염두에 두고 재설계한다면 아직 자바스크립트로도 충분히 성능을 올릴 수 있다.
- 바이트코드 캐시와 JIT 컴파일러는 자주 사용되는 코드에 대한 성능 최적화를 해준다. 그 경우 "더 빠른 언어"로 작성된 것에 비해 성능적으로 밀리지 않는다.
- 기여와 디버깅의 관점에서, 자바스크립트 사용자가 자바스크립트 툴링에 기여하지 못하고 디버깅하지 못한다는 것은 개발 환경과 생태계에 있어서 너무 좋지 않다.
잘 모르기는 하지만, 글만 본다면 글쓴이의 주장은 충분히 합리적으로 보인다.
React
Drag to Select
React 에서 추가적인 라이브러리 사용 없이 " 드래그로 여러 아이템을 선택" 하는 기능을 만드는 글. 내용이 상세하고 알차다. 특히 스크롤 가능한 엘리먼트 내에서 대응하는 것이 깔끔하다.
Frontend
[GeekNews] 이제는 피해야 할 낡은 HTML 작성 스타일 7가지
간단하고 유용한 팁들. <details> 와 <summary> 태그를 사용해서 JS 없이 아코디언 UI 를 만드는 게 제일 인상깊다. 원문을 보면 간단한 예제코드들도 같이 볼 수 있다.
How Microsoft Edge Is Replacing React With Web Components
Edge 브라우저가 기존에 React 로 구현되어 있던 많은 부분을 웹 컴포넌트로 대체하고 있다는 기사.
- React 의 성능이 좋지 않다. 특히 저사양 기기에서 두드러지는데, 이는 Edge 팀이 React 를 좋지 않은 방식으로 사용하는 것도 영향이 있다.
- Edge 의 엔진을 Chromium 으로 갈아타면서 Chrome 과 UI 차별성을 두기 위해 UI 부분을 React 로 재구성했었는데, 결국 이 부분들을 다시 (점진적으로) 웹 컴포넌트로 대체하는 중이다.
- 웹 컴포넌트를 사용함으로써 브라우저의 built-in 엘리먼트들을 더 잘 활용할 수 있게 되었고, 개발자와 디자이너들이 HTML/CSS 로 같이 작업하면서 생산성이 더 좋아졌다.
- Microsoft 의 다른 팀들이 어떻게 생각할지는 모르겠으나 우리는 이 이전 작업을 잘 끝내고 싶다.
그래서 웹 컴포넌트로 옮기면서 퍼포먼스가 얼마나 개선되었는가 에 대한 내용은 없는 것 같다. 아직 옮기는 중이라 공유할만한 수치는 없는 모양.
기사는 아직은 논란이 있는 웹 컴포넌트에 대한 의견도 공유하고 있다.
- SolidJS 창시자가 Web Components Are Not the Future 라는 글로 "웹 컴포넌트가 기존 프레임워크보다 안 좋다" 라는 취지의 글을 작성
- 그것에 대해 (웹 컴포넌트 라이브러리인) Shoelace 창시자가 "웹 컴포넌트가 훨씬 안정적이며, 웹 컴포넌트와 기존 프레임워크는 배타적이지 않아서 같이 상호 보완적으로 사용할 수 있다." 라는 코멘트로 반박
Engineering
Component Composition is great btw
컴포넌트 합성을 통해 코드를 좀 더 가독성 및 재사용성이 좋게 개선하는 방식을 제안하는 글. 이 글에서 중점적으로 다룬 것은 layout 컴포넌트 작성과 early return 적용.
글에 나온 방식이 단 하나의 정답이라기보다는, 이러한 형식이 코드도 있다는 관점에서 읽어볼만한 글. (개인적으로는 좋아하는 형식이다.)
정규식을 이용한 공격 - ReDos
정규표현식 엔진의 취약성을 이용해 서비스에 부하를 거는 공격에 관한 글.
- 정규표현식 엔진에서 사용하는 알고리즘의 이슈로, 해당 알고리즘에서 특정 정규표현식에 특정 형식의 문자열을 대입했을 경우 평가가 지나치게 오래 걸리는 것을 악용해 서비스에 장애를 일으킨다.
- 이미 몇 년 전에도 Momont.js, Stack Overflow, Cloudflare 등에서 취약점이 발견되거나 서비스 장애로 이어진 적이 있다.
- 실제 취약점 및 장애를 일으켰던 정규표현식도 소개하고 있다.
- 정규표현식의 위험도를 측정할 수 있는 툴도 있다.
Etc
The WordPress vs. WP Engine drama, explained
WordPress(워드프레스 오픈소스를 관리하는 비영리재단) 와 WP Engine(워드프레스로 호스팅 서비스를 제공하는 상업 서비스) 간의 분쟁이 격화되고 있는데, 이 둘의 분쟁을 타임라인 순으로 정리한 기사이다.
영어를 읽기가 불편하거나 귀찮다면 WordPress 랑 WP Engine 이슈 간단 정리 글도 읽어볼만 하다. 위 기사만큼의 최신 정보는 아니지만 상황을 이해하는 데에는 큰 무리가 없다.
개요를 간략히 정리하자면, 먼저 WordPress 가
WP엔진이 워드프레스와의 상표 유사성을 통해 부당 이득을 취하고 있다. 워드프레스 오픈소스에는 전혀 기여하지 않으면서 워드프레스를 사용해 돈만 벌고 있다.
위와 같은 주장으로 불만을 제기하고, WP Engine 은
우리는 워드프레스의 라이선스(GPLv2)를 위반하지 않고 있다.
라고 대응하고 있다.
이 과정에서 WordPress 측이 WP Engine 로부터 워드프레스 저장소에 접근할 권한을 막으면서, 이 분쟁은 단순한 둘의 분쟁이 아닌 오픈소스 생태계에 대한 위협으로 받아들여지고 있다.
몇몇 유명 개발자나 블로거들도 "Automattic(WordPress 소유 회사) 이 오픈소스 생태계를 망치고 있다"며 WordPress 측을 비난하고 있다.
GN⁺: WordPress 보복이 커뮤니티에 미치는 영향 또한 같이 읽어볼만 하다.
이 사태가 어떻게 흘러갈지 여러모로 궁금하다.